53688
組み込みLinuxやUNIXのGUIについて質問です。  
工業機器やカーナビ、ゲーム機などLINUX/UNIXで動いているアプリケーションのGUIはどのように描画されているのですか？  
起動時にGNOMEやMATE、XFCEのようなX Windowデスクトップは見えないですが、Xウィンドウマネージャー上に描画しているのでしょうか？  
それともXlibの上、もしくはX.org上に直接描画しているのでしょうか。

抽象的な質問ですが、お教えいただけると幸甚です。  
よろしくお願いいたします。

追記：組み込みという表現が少し誤解を与えてしまったかもしれません、例えばTeslaのセンターディスプレイや、PlayStationのメインメニューなどのような高解像度なグラフィックを想定して質問させていただきました。
CC BY-SA 4.0
2019-03-22T16:00:22.270
53659
2019-03-31T06:09:12.573
2019-03-31T06:09:12.573
32622
32622
question
linux gui
組み込みLinuxのGUIについて
組み込みシステムは限られた容積、CPUパワーやメモリ容量で動作しなければならないという制約を受けます。そのためX
windowsのように複雑な表示機能を持つものは稀で、CUI(Character-based User
Interface)だけのものも多いです。CUIであれば３本ケーブルのシリアル通信で入出力できるので小規模システムでも導入できます。
CC BY-SA 4.0
2019-03-23T12:44:33.170
53677
2019-03-23T12:44:33.170
217
53659
answer
昔から組み込みにもGUIはたくさんあります。  
XWindowSystemやアプリケーションを作成するSDKは最終的に１枚の画像データを生成します。  
その画像データをkernel層に渡しメモリにセットしLCDへ転送していきます。

１枚の画像データを生成出来れば例えばopenglでプログラムを組んで  
libglから得られた画像データをkernel層に渡しLCDへ表示すればGUI表示できます。

質問にありましたが  
アプリケーションSDKやXWindowでは  
キャンバス上に描画していくだけにすぎず  
その出来上がった画像データをLCDまで実際に描画するとは別物です。

組み込みLinuxの描画というキーワードがあるので補足しますが、  
/dev/fb0（フレームバッファ）に書き込めば描画されるわけでは無く、  
/dev/fb0に書き込むとuserspaceからkernelspaceへシステムコールが行われ、  
kernel層では画像データを受け取りLCDなどへ転送する処理などを行っていきます。  
組み込み開発では、userspaceだけでなくkernelspaceの開発も入ってくる事の方が多いです。
CC BY-SA 4.0
2019-03-24T05:12:30.787
53684
2019-03-25T15:41:55.643
2019-03-25T15:41:55.643
32285
32285
53659
answer
関係者(中の人)が答えてくれるのがベストですが、外側から考えると以下のようになるでしょう。

**[フレームバッファ](https://en.wikipedia.org/wiki/Linux_framebuffer)という技術を使う**  
[fb/framebuffer.txt](http://archive.linux.or.jp/JF/JFdocs/kernel-
docs-2.6/fb/framebuffer.txt.html)

> Linuxフレームバッファ（fbdev）は、グラフィックをハードウェアに依存しない抽象レイヤで、コンピュータのモニタ（通常はコンソール）に表示します。  
>
> フレームバッファという語は現在のビデオフレームを含むビデオメモリの一部を意味し、LinuxフレームバッファはSVGALibや他のユーザ空間ソフトウェアのようなシステム特有のライブラリに頼ることなく、「Linuxカーネルの下でのフレームバッファへのアクセス方法」を意味します。

グラフィックスデータ用のメモリが(少し工夫は必要だが)普通のメモリのようにアクセスできるので、そこにGUIのデータを直接書いて行く方法

使い方例：[ラズパイでフレームバッファ(/dev/fb0)を使用して、直接ディスプレイ画像を入出力する](https://qiita.com/take-
iwiw/items/0a7a2fefec9d93cdf6db)  
少し古いですがツールの調査：[組込み機器向けHMI/GUIツール調査(2017.10時点)](https://medium.com/munes-
diary/%E7%B5%84%E8%BE%BC%E3%81%BF%E6%A9%9F%E5%99%A8%E5%90%91%E3%81%91hmi-
gui%E3%83%84%E3%83%BC%E3%83%AB%E8%AA%BF%E6%9F%BB-2017-5%E6%99%82%E7%82%B9-eb5c87e4022)  
上記記事に出ていた中の、いくつかのツールの紹介ページ(製品によっては次のコマンド直接送信サポートも含むかも)

  * [Qt for Embedded Linux](https://doc.qt.io/qt-5/embedded-linux.html) / [組み込み Linux のサポート](https://wiki.qt.io/Support_for_Embedded_Linux/ja)
  * [TouchGFX](https://www.uquest.co.jp/middleware/touchgfx.html)
  * [GENWARE](http://www.ilc.co.jp/commodity/genware4/)
  * [EMConnect](https://www.miraclelinux.com/product-service/total-embedded/emconnect) / [EMBrowser](https://www.miraclelinux.com/product-service/total-embedded/emconnect/embrowser)
  * [exbeans UI Conductor](https://armadillo.atmark-techno.com/software/uiconductor)
  * [QNX® SDK for Apps and Media(アプリとメディア用QNX® SDK)](http://blackberry.qnx.com/jp/products/apps-media/index)
  * [Crank Storyboard Suite](https://www.cranksoftware.com/storyboard-suite)

ライブラリ情報

  * [Choosing a GUI Library for Your Embedded Device](https://www.linuxjournal.com/article/9403)
  * [Microwindows or the Nano-X Window System](https://github.com/ghaerr/microwindows)
  * [LittlevGL - Open-source Embedded GUI Library](https://littlevgl.com/)
  * [MiniGUI](http://www.minigui.org/)
  * [µGFX](https://ugfx.io/)
  * [GLG Toolkit](http://www.genlogic.com/free_embedded_graphics.html)

**表示装置の制御コマンドを直接送信する**  
シリアル(RS232/RS422/I2C/SPI/etc.)/パラレル等に接続された表示装置の提供している制御方法でコマンド&データを作成・送信して表示を行う  
表示装置の設計次第で、低機能(キャラクタ/ビットデータ)から高機能(Canvas/SVG相当や3D/アニメーション等)まで様々なバリエーションが考えられる  
メーカーがライブラリや開発環境/ツールを提供していたりする

例えば：[128×64モノクログラフィックLCDシールド](https://www.switch-science.com/catalog/2841/) /
[LCDドライバICのデータシート](https://synapse.kyoto/product/MGLCD_12864/pdf/uc1601-v1-0d.pdf)  
[グラフィック組込みモジュール](http://www.hitachi-ul.co.jp/system/g-module/index.html)  
[組込み機器の可能性を無限に引き出すグラフィックスLSI「AG10」](https://monoist.atmarkit.co.jp/mn/articles/1105/09/news001.html)  
[グラフィックLCD開発ソフトウエア Visual GLCD [GLCD-1A]](http://www.microtechnica-
shop.jp/shopdetail/000000000073/)
CC BY-SA 4.0
2019-03-24T08:56:26.733
53688
2019-03-24T09:02:54.900
2019-03-24T09:02:54.900
26370
26370
53659
answer
モノによって異なります。組み込みだからといってXが使われないわけではありません。

  1. 通常のX+ウィンドウマネージャの構成だが、アプリケーション自体またはウィンドウマネージャのキオスクモード的な機能により1ウインドウに見せかけているもの
  2. Xで動くが、ウィンドウマネージャを使わないもの
  3. Xを使わずに、Linuxのフレームバッファのような、OSのグラフィックス抽象レイヤを操作するもの
  4. グラフィクスハードウェアを直接または専用のライブラリ経由などで操作するもの

上の方が高機能でできることは増えますが要求するリソース(プロセッサのパフォーマンス、消費電力、メモリ、フットプリント、その他)は大きくなります。逆の見方をすると、リソースに余裕があるなら上の方のやり方を選択するほうが(一般には)簡単です。

リソースが限られている場合(または、リソースをギリギリまで使うためにオーバーヘッドを排したい場合)は必然的に下の方を選択せざるを得ないことになります。

また、Qtのように、2.3.の違いをある程度隠蔽してくれるGUIツールキットを使うことで、開発段階ではXで動かし、実機ではXなしということもあります。

あと、

> 起動時にGNOMEやMATE、XFCEのようなX Windowデスクトップは見えないですが、Xウィンドウマネージャー上に描画しているのでしょうか？

ここは若干誤解があるように思います。

Xのウィンドウマネージャは、アプリケーションに対しては(すごく大雑把に言うと)枠をつけているだけです。アプリケーションの中身の描画はウインドウマネージャではなくXのレイヤで行われています。なので、ウインドウマネージャをすげ替えても動くわけです。

> それともXlibの上、もしくはX.org上に直接描画しているのでしょうか。

組み込みかどうかは関係なく、X.orgを直接操作する(=自前でXプロトコルをしゃべる)アプリケーションというのはほぼなく、Xlibやさらに上位のライブラリ経由です。
CC BY-SA 4.0
2019-03-25T12:43:14.487
53721
2019-03-25T12:43:14.487
5793
53659
answer