Linux GUI子系統概述 GUI子系統的構成及工作流程

Linux GUI子系統概述 GUI子系統的構成及工作流程

Nick 發表於 2020-12-05 10:45:54

作者：Nick

開始前的幾點說明：

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

對於系統的介紹，分析的著重點可能不會在於為什麼該這樣設計，而是在於在現有的顯示系統下，我們能做些什麼來適配我們的目的；

1.前言

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

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

著重分析Linux下DRM+KMS的軟體實現方式，並且以Xilinx的Zynq-7000 SOPC為例，詳細介紹相關片內硬體模塊在GUI系統中的角色及實現方式；（由於GPU模塊硬體的源碼的開源程度不高，不在本文的分析範圍內）

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

本文的最後一部分，會在Zynq-7000上面（digilent的Zybo開發板）部署整個Linux+硬體邊緣提取處理+Qt+HDMI的環境，並給出具體的實現流程；

2.Linux GUI子系統概述

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

窗口系統一般都具備以下基本功能：

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

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

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

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

X server：負責軟硬體的管理，將輸入的軟硬體事件通過一定協議轉發給X client，將輸出的圖形繪製在屏幕上；

X client：每個需要涉及到GUI的App，可以實例化為一個X client，X client主要是響應X server分發下來的事件，通過處理後，將待繪製的圖像回傳給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： 提供登陸許可環境以獲得X Window的控制

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

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

3.Linux GUI子系統的構成及工作流程

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

即按照一定時序時序，將圖像信息從內存中輸出到顯示接口上。若在生成Frame buffer裡面的圖像數據時不僅通過軟體memory處理，還用到了硬體加速的話，數據流則變為如下：

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

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

DRM主要負責負責數據流，即通過軟體或硬體，生成目標圖像，存儲在framebuffer中；

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

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

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

4.我們能做些什麼

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

編輯：hfy

打開APP閱讀更多精彩內容

聲明：本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人，不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用，如有內容圖片侵權或者其他問題，請聯繫本站作侵刪。 侵權投訴