首页 > *nix技术 > Linux图形子系统

Linux图形子系统

2022年11月13日 发表评论 阅读评论 2,343 次浏览

一，参考

https://unix.stackexchange.com/questions/345344/difference-between-xorg-and-gnome-kde-xfce

1，Windowing system，窗口系统：实现窗口、图标、菜单、鼠标指针的用户操作接口。
Display server，窗口系统的关键组件是显示服务器（或窗口服务器、合成器compositor）。在窗口中显示其GUI的任何应用程序都是显示服务器的客户端。
由于涉及客户端和服务器，所以通信协议是必要的，这当然称为显示服务器协议。

显示服务器是一个程序，其主要任务是协调其客户端与操作系统其余部分、硬件以及彼此之间的输入和输出。它提供了图形硬件的抽象，以供图形界面的更高级别（GUI系统具有分层设计）元素（如窗口管理器）使用。
显示服务器举例：
X.Org server (mostly for *nix)
Wayland (mostly for *nix)
Mir (mostly for *nix)
SurfaceFlinger (This is for Google Android.)
Quartz Compositor (This is what Apple MacOS uses.)
Desktop Window Manager (This is what Microsoft Windows uses.)

X, X11 and X Window System是同一个意思，其包括：
display server
display server protocol
some libs for development
and other things

2，Window Manager
Gnome/Xfce/KDE都是窗口管理器，因为它们都在X显示服务器上工作，所以它们都被称为X窗口管理器。窗口管理器与X服务器和X客户端协作。
GNOME、KDE和Xfce桌面都是Linux桌面环境。桌面环境是在操作系统上运行的程序包，它们共享一个通用的GUI。

3，display manager

https://wiki.debian.org/DisplayManager

gdm3, lightdm, kdm都是显示管理器。
就我个人而言，我认为Display Manager是一个误导性的名称。最好叫图形登录管理器。它通常是在引导过程结束时显示的图形用户界面，而不是默认的shell。
不同的桌面环境使用不同的登录管理器来保持视觉风格的一致性。
GNOME use gdm3.
Xfce use lightdm
KDE use kdm

4，总结：
GUI可以有多种类型。窗口系统是GUI的一种类型。
任何窗口系统的关键组件通常称为显示服务器。
窗口系统（如X）抽象了硬件和IO。它提供绘制和移动窗口以及IO处理等基本服务。
窗口管理器，如Gnome、Xfce、KDE，工作在显示管理器之上，提供您看到的外观和感觉。
桌面环境是一组共享共同视觉风格的应用程序。
显示管理器或图形登录管理器提供图形登录界面。

二，OpenGL、OpenGL ES、OpenVG、GLX、EGL的简介
参考：https://blog.csdn.net/Cappuccino_jay/article/details/125225930

https://blog.csdn.net/z1026544682/article/details/117331160

xserver提供X服务，X server 不是指某台机器，而是指一个进程，它负责接受客户的要求，在屏幕上显示客户请求的图形，并且把消息(键盘，鼠标，窗口消息)通知客户程序。
xclient是X应用终端。

OpenGL是行业领域中最为广泛接纳的2D/3D图形API。
OpenGL依赖各平台提供用于渲染的context以及具体实现方式，而各平台提供的实现不尽相同。这些实现主要有：Windows平台下的WGL、Linux下的Mesa/GLX、Mac OS X下的Cocoa/NSGL，以及跨平台的GLUT、GLFW、SDL等等。

Mesa是Linux下的OpenGL实现。它提供了对AMD Radeon系列、Nvidia GPU、Intel i965, i945, i915以及VMWare虚拟GPU等多种硬件驱动的支持，同时也提供了对softpipe等多种软件驱动的支持。Mesa项目由Brian Paul于1993年8月创建，于1995年2月发布了第一个发行版，此后便受到越来越多的关注，如今Mesa已经是任何一个Linux版本首选的OpenGL实现。

GLX则是在Linux上用于提供GL与窗口交互、窗口管理等等的一组API。它的作用与Windows的WGL、Mac OS X的AGL以及针对OpenGL ES的EGL相似。在Linux上，窗口创建、管理等API遵循X Window接口，而GLX提供了OpenGL与X Window交互的办法。因此GLX也可以运用于其他使用X Window的平台，例如FreeBSD等。
GLX是OpenGL Extension to the X Window System的缩写。它作为x的扩展，是x协议和X server的一部分，已经包含在X server的代码中了。GLX提供了x window system使用的OpenGL接口，允许通过x调用OpenGL库。OpenGL 在使用时，需要与一个实际的窗口系统关联起来。在不同平台上有不同的机制以关联窗口系统，在Windows上是WGL，在Linux上是GLX，在 Apple OS上是AGL等。

EGL则是OpenGL ES在嵌入式平台上（WGL,GLX,AGL）的等价物。EGL假设OS会提供窗口系统，但EGL与平台无关，并不局限于任何特定的窗口系统，所有用到本地窗口系统的地方都用屏蔽指针来处理。我觉得这就是它易于移植的关键。

Mesa 3D是OpenGL的一个开源本的实现，支持3D硬件加速，X.Org和DRI都使用它作为OpenGL驱动。
DRI是Direct Rendering Infrastructure的缩写。DRI是一个安全且有效率的直接对显示硬件存取的方法。它包含对X server,一些client函数库、以及对内核的变更。DRI的一个主要目的就是提供高效能的OpenGL支持。
XGL项目由Novell发起，是一个X server架构，其设计意图在于通过OpenGL驱动充分发挥最新显卡的功能，支持所有X、OpenGL和XVideo的硬件加速。该项目最初于 2006年1月在X.Org中发布，但随后由于AIGLX的出现，在2008年1月被X.Org抛弃。Xgl可以使用Xglx和Xegl作为后台的 server。作为其衍生品，compiz和Xgl是完全兼容的。

AIGLX是Accelerated Indirect GLX的缩写。该项目由Red Hat和Fedora社区发起。此处Indirect的含义在于：client端应用程序的OpenGL命令首先送给X server，再通过X server调用显卡驱动层的OpenGL接口，这里X协议走的是GLX。Xgl则是另外一种方式：建立一个OpenGL窗口，由OpenGL库直接调用显卡驱动。X.Org 7.1开始，已经加入了AIGLX。

Xglx是Xgl框架的一个后台 server，但他仍然需要一个现有的 x server，Xglx通过x server的GLX创建OpenGL窗口，然后使用它，类似于Xnest；同时，Xglx还对x server做一些使用OpenGL显示和绘图的初始化操作。尽管使用另外一个x server显得多余，Xglx却避免了和不同的图形硬件直接打交道。

Xegl是Xgl框架的另一个后台server，继承了Xglx中绘图相关的代码，但它对OpenGL环境的初始化部分，调用的是EGL接口（而非Xglx使用的GLX）。由于一些硬件的闭源驱动不提供支持EGL的接口，Xegl的开发有些停滞。

三，参考 ★★★★★
Linux系统中少有的图形子系统分析：https://zhuanlan.zhihu.com/p/553974712

https://kernel.0voice.com/forum.php?mod=viewthread&tid=709

http://www.wowotech.net/graphic_subsystem/dri_overview.html

原出处应该是这个：http://www.wowotech.net/sort/graphic_subsystem

这两篇文章讲得很好，可惜原本计划的后续内容没有写了。。。
里面有个对录屏的说明，Mark下：


wowo 提个问题，在DRM/KMS显示框架下应该如何录屏呢？
FrameBuffer显示框架下录屏比较容易实现。
谢谢~
回复
wowo
2016-01-25 08:39
@momo：录屏不应该和底层的实现有关，因此一般都在合成器（Composer）里面做。例如Android，录屏也是一个Display device，只是目的地是内存。
回复
momo
2016-01-25 10:44
@wowo：谢谢wowo。录屏的确是应用层的事情，但底层应该开放相应的entity给应用录屏，比如说
FrameBuffer显示框架可以通过访问/dev/fb0来录屏，Android应该也可以访问/dev/ graphics/fb0来录屏（没做过Android，此处仅是猜测）。DRI开放给应用程序的entity有/dev/dri/card0和/dev/dri/controlD64，而据我所知都不能用来录屏（也许可以只是我不知道）。所以想请教一下wowo，在DRI显示框架下，有什么好的办法或者建议来录屏？
回复
wowo
2016-01-25 15:16
DRI所在的应用场景，远比Framebufffer复杂，因为硬件可以做很多事情，我们举一个支持双显的例子（这在现今的消费类系统是很常见的）：

Plane 0--------------\
                                |
Plane 1----------\    |
                            |   |
                           V V
Plane 2---->CRTC0------>Encoder0---->LCD
      (Scanout buffer 0)

Plane 3----------\
                           |
                          V
Plane 4---->CRTC1------>Encoder1---->HDMI
      (Scanout buffer 1)

问题的关键点是：
1）Application可以同时送给DRI 7个framebuffer（Plane和Scanout buffer都是由framebuffer表示）。
2）而我们的硬件（CRTC），可以对这多个buffer自行处理（缩放、叠加、Alpha混合等）后，驱动显示控制器（Encoder）输出。

在这个过程中，我们不能简单的抓取任何一个framebuffer就可以完成屏幕录像。如果要做，只能在如下的2几个地方做：
1）我们的CRTC在将合成后的图像送到Encoder的时候，同时送一份给内存，其实就是硬件的回写功能。
2）由Application自行完成（这里的Application可能是合成器，如Wayland）。Application在将buffer送给CRTC的同时，调用软件API（OpenGL等））将这些buffer合成为一个，然后保存成文件。至于合成器是够提供这个功能，我也不是很清楚，要看你是使用什么样的GUI系统。

当然，如果系统没有Plane，每个CRTC也就只有一个Scanout buffer，就可以将DRI降级为简单的framebuffer设备。旧的方法（/dev/fbX）依旧是可行的。
回复
momo
2016-01-26 10:56
@wowo：谢谢wowo，讲得很清楚~
准备使用硬件的回写功能来实现，对我这样的新手是个挑战。

四，参考

https://people.freedesktop.org/~marcheu/linuxgraphicsdrivers.pdf

https://www.jianshu.com/p/fbdfcec8d989

https://www.jianshu.com/p/50405e326127

https://zhuanlan.zhihu.com/p/555679523

五，参考 ★★★★★

https://blog.csdn.net/hexiaolong2009/article/details/83720940

转载请保留地址：http://www.lenky.info/archives/2022/11/3253 或 http://lenky.info/?p=3253

备注：如无特殊说明，文章内容均出自Lenky个人的真实理解而并非存心妄自揣测来故意愚人耳目。由于个人水平有限，虽力求内容正确无误，但仍然难免出错，请勿见怪，如果可以则请留言告之，并欢迎来信讨论。另外值得说明的是，Lenky的部分文章以及部分内容参考借鉴了网络上各位网友的热心分享，特别是一些带有完全参考的文章，其后附带的链接内容也许更直接、更丰富，而我只是做了一下归纳&转述，在此也一并表示感谢。关于本站的所有技术文章，欢迎转载，但请遵从CC创作共享协议，而一些私人性质较强的心情随笔，建议不要转载。

法律：根据最新颁布的《信息网络传播权保护条例》，如果您认为本文章的任何内容侵犯了您的权利，请以Email或书面等方式告知，本站将及时删除相关内容或链接。

分类: *nix技术 标签: ,
  1. 本文目前尚无任何评论.
您必须在 登录 后才能发布评论.