作者：Nick

開始前的幾點說明：

本文會盡量從初學者的角度去描述整個Linux整個圖形子系統(tǒng)，但由于其復雜性，涉及到的模塊比較多，可能會需要一些相關的先驗知識；

對于系統(tǒng)的介紹，分析的著重點可能不會在于為什么該這樣設計，而是在于在現(xiàn)有的顯示系統(tǒng)下，我們能做些什么來適配我們的目的；

1.前言

GUI作為人機交互信息量最大的一種方式，無論在消費還是工業(yè)級產(chǎn)品上都大行其道。但同時由于它處在整個系統(tǒng)的核心位置，對外需要通過鼠標、鍵盤 、顯示器進行I/O獲取和控制，在內(nèi)需要負責圖形的生成，渲染，整個系統(tǒng)復雜度比較高。本文會從以下幾個 方面來介紹GUI子系統(tǒng)：

以Linux下的原生GUI子系統(tǒng)為例，概述GUI子系統(tǒng)的概念，軟硬件部分在GUI子系統(tǒng)的中的角色及大致構成；

著重分析Linux下DRM+KMS的軟件實現(xiàn)方式，并且以Xilinx的Zynq-7000 SOPC為例，詳細介紹相關片內(nèi)硬件模塊在GUI系統(tǒng)中的角色及實現(xiàn)方式；（由于GPU模塊硬件的源碼的開源程度不高，不在本文的分析范圍內(nèi)）

分析現(xiàn)有GUI框架下，在硬件加速方面，我們能做的事情，并以非常簡單的圖像處理為例，給出相應的設計方案；

本文的最后一部分，會在Zynq-7000上面（digilent的Zybo開發(fā)板）部署整個Linux+硬件邊緣提取處理+Qt+HDMI的環(huán)境，并給出具體的實現(xiàn)流程；

2.Linux GUI子系統(tǒng)概述

GUI作為人機交互的一種方式，通過其承載的大量信息提高了信息交流的效率。這里我們不介紹鼠標、鍵盤等輸入設備，只介紹輸出顯示這一子模塊。生活中大家最常見的圖形化界面估計就是圖像化界面的桌面環(huán)境，即窗口系統(tǒng)，（如下圖的Ubuntu、Xfce等）。

窗口系統(tǒng)一般都具備以下基本功能：

通過WIMO（Window-視窗、Icon-圖標、Menu-選單、Pointer-指標）4個基本元素來實現(xiàn)人機交互；

上述的4個基本元素都能通過第三方的程序來擴展（也就是安裝新程序）；

在實現(xiàn)方式上，大部分Linux下的窗口系統(tǒng)都是通過X來響應不同的交互請求及輸出到顯示器上。因此，整個應用層的GUI結構如下：

因此，在應用層面上，GUI系統(tǒng)的核心部分是X，X的總體功能一句話描述如下：通過指定的協(xié)議接受本地或遠程的鼠標、鍵盤需求，并切輸出相應的窗口畫面到顯示設備上。細分來講，X主要由以下4個組件構成：

X server：負責軟硬件的管理，將輸入的軟硬件事件通過一定協(xié)議轉(zhuǎn)發(fā)給X client，將輸出的圖形繪制在屏幕上；

X client：每個需要涉及到GUI的App，可以實例化為一個X client，X client主要是響應X server分發(fā)下來的事件，通過處理后，將待繪制的圖像回傳給X Server；

X window manager：X window manager作為一個特殊的X client，主要負責為X server管理多個X client（一個具體的例子就是對虛擬桌面的管理），起著視窗管理員的角色。常見的X window manager如下:

. GNOME (GNU Network Object Model Environment);
. KDE (K Desktop Enviroment)
. twm (Tab Window Manager)
. XFCE (XForms Common Environment)
. Display manager： 提供登陸許可環(huán)境以獲得X Window的控制

我們再從開發(fā)者的角度來看一下GUI。以Qt為例，我們在使用Qt組件進行開發(fā)時，一般是利用組件中的各種類庫，去響應各種事件輸入（單雙擊鼠標、鍵盤操作）以及給出相應的輸出到顯示器上。其實際工作的時候，這些工作底層都是通過和window system（X）之間的交互實現(xiàn)的。

這些基本事件的響應，基本的圖像單元的繪制，是window system通過封裝成一個通用的GUI工具集提供給QT（如X的xlib）。對于Qt而言，這個window system可以是X，也可以是QT自行研發(fā)的QWS視窗系統(tǒng)。整個應用層的GUI系統(tǒng)則可看作如下：

3.Linux GUI子系統(tǒng)的構成及工作流程

從應用層深入到內(nèi)核中去。暫不考慮在linux下的GUI，我們知道，單純的顯示圖片的話，整個數(shù)據(jù)流的走向是這樣的：

即按照一定時序時序，將圖像信息從內(nèi)存中輸出到顯示接口上。若在生成Frame buffer里面的圖像數(shù)據(jù)時不僅通過軟件memory處理，還用到了硬件加速的話，數(shù)據(jù)流則變?yōu)槿缦拢?/p>

其中accelerate logic就是顯卡部分（若是SOC的片內(nèi)GPU模塊，則是通過片內(nèi)高速總線進行數(shù)據(jù)交互的，若若是獨立顯卡，一般是通過pci-e高速串行接口進行數(shù)據(jù)傳輸?shù)模０堰@個數(shù)據(jù)流走向放入Linux中，數(shù)據(jù)流和控制流都需要和用戶層進行交互，也就是說，Linux下，必須得有相關的軟件驅(qū)動給用戶層提供相應的API。這也就是DRM（Direct Rendering Manager）和KMS（Kernel Mode Setting）的角色。

Linux原生系統(tǒng)中提供由DRM+KMS構成的DRI（Direct Rendering Infrastructure）中：

DRM主要負責負責數(shù)據(jù)流，即通過軟件或硬件，生成目標圖像，存儲在framebuffer中；

KMS主要負責控制流，即針對外置LCD以及指定的顯示模式設置，將生成好了的frame數(shù)據(jù)信息送到響應display port上（VGA、HDMI等）；

Kernel將這兩大快的基本API抽出來封裝成libdrm供X使用，整個應用層+kernel相關的GUI結構如下圖：

整個data flow也替換成了上圖的flow1~flow6。關于DRM和KMS的詳細介紹我們會放到這個系列的第2篇，這里再提一下涉及到3D的GUI。在需要用到3D圖形交互的場景，往往對著實時性要求較高，X中的server/client之間的數(shù)據(jù)協(xié)議解析以及數(shù)據(jù)交互導致的延時是這種場景不能容忍的。因此DRI是支持這種app越過X直接和內(nèi)核交流的方式的。比如，Qt中可以直接通過opengl相關類庫直接調(diào)用libdrm中API控制硬件中的Frambuffer軟硬件，此時結構如下：

4.我們能做些什么

在一個常見的系統(tǒng)研發(fā)中，子系統(tǒng)中我們能做的基本就是適配，適配不同的CPU、適配不同的OS、適配不同的顯示設備。而對于專業(yè)的GPU研發(fā)團隊來說，則需要在現(xiàn)有DRI框架下，為自己的GPU邏輯設計專用的驅(qū)動，軟硬件工作量龐大。作為一個高性能計算實驗室，當然要將一些高速計算融進去。在本系列第3篇，我們將會在Xilinx的Zynq7000系列芯片上，利用其中的PL邏輯資源，設計非常簡單的圖像處理IP，加速DRM中的Framebuffer數(shù)據(jù)并通過HDMI顯示到LCD上。

編輯：hfy