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

Linux图形子系统

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

一,参考

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/3253http://lenky.info/?p=3253


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

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

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