哈喽,我是老吴。
今天给大家分享一些关于 Linux 图形显示的要点,这些要点构成了 Linux 图形显示的框架。
希望对大家有帮助!
当我们看到一个东西并在脑子里产生它的样子时,本质上是眼睛感受到了光。
所以,图形是光的数字化呈现,形式为图片 (picture) 或者叫帧 (frame),picture 和 frame 本质上是一样的东西。
物理世界中的光是连续的,而数字图片是离散的或量化的;
数字图片由许多的像素 (pixel) 构成的,如何用数字来表示每一个像素的方式称为 color model,例如包含 3 个 color channel 的 RGB,而具体用多少位的数据来表示某个具体的颜色值的方式称为 color space,
color model 是描述了颜色的组成方式,而 color space 则是物理图形世界和数字图形世界的准确链接方式。
下面是关于图片的几个要点:
1、图片的尺寸 (dimension,宽度和高度),以像素为单位。
2、纵横比 (aspect ratio) 是宽:高的比例,例如 16:9、4:3。
3、分辨率 (resolution),像素个数/物理长度,可能是 pixels per inch 或者是 pixels per millimeter,容易和 dimension 混淆。
4、根据像素在内存中的存储顺序的不同,显示时也会有不同的扫描顺序 (scan order),例如 linear scan order、raster scan order。
5、像素有特定的格式:
Graphics 相关
Displaying: 根据数码图片的数据,重现相应的光,例如显示器、屏幕、投影仪。
Rendering: 根据 primitives (渲染时用的术语,其实就是 points、lines 等最基础的元素) 生成数码图片,包括 3D rendering, 2D shape drawing, font rendering 等。
Processing: 处理数码图片,包括 Filtering, scaling, converting, compositing 等。
Media 相关
Decoding/encoding: 压缩/解压缩图片,Picture codecs (JPEG, PNG, etc), Video codecs (H.264, VP8, etc)。
Capturing/outputting: 采集或者输出图像,例如 Cameras, DVB 等。
包括 Display、Rendering and Processing 相关的硬件。
显示输出是通过下面的组件实现,这些组件就构成了一条 pipeline:
Frame buffer:一块用于存储像素的内存,可能有多个 Frame buffer,一个 Frame buffer 就对应一个图层 (plane);
Display engine:充当 hardware compositer 的角色,负责对图层 (plane) 进行合成,例如将鼠标图层,视频图层、桌面图层合成在一起;
Timings controller:当我们已经拥有了一张已经合成好的图片后,我们就需要通过 Timings controller 将像素以正确的时序发送出去。由于都会兼容以前的 CRT 显示器,所以也叫 CRT controller,简称 CRTC。
Display protocol controller:当像素能以正确的时序发送时,它们就会到达 Display protocol controller,这里会将像素以某个格式打包,或者叫编码以满足相应的协议,例如 HDMI、eDP、MiPi dsi 的数据包都有各自的编码格式。
Display interface PHY:负责物理链 路上信号的发送和接收,例如 HDMI 的 tmds (transition minimized differential signaling),现在一般都是差分信号,并且不断地追求更大的吞吐量。
Connector and cable:最后就是通过线缆连接到显示设备,例如显示器、屏幕。
在 Soc 的显示模块里,一般都会包含 Display engine、Timings controller、Display interface PHY。
Rendering 和 Processing 有几种不同的实现:
GPU(图形处理单元):
DSP(数字信号处理器):
固定功能 ISP(图像信号处理器):
基于 CPU 的实现
包括 Display、Render 两个类型。
1、某个时刻,只能有一个应用访问显示设备,不同 app 的显示需求应该被合成一张图片然后再被显示出来,因此需要一个叫 display server 的处理这些事情;
2、display server 负责:
3、compositor 是另外一个常见的概念,一般会集成在 display server 中,它负责将各个 client app 的 buffer 合成一张图片,然后将其发送给显示设备。
4、window manager 也是一个比较重要的概念,它负责定义 client app 的共存策略,例如哪个 app 位于最上层、哪个应用被选中了、哪个应用正在被移动;
1、与显示不同,GPU 可以并行运行不同的工作;
2、GPU 渲染基于 primitives,其实就是点、线之类的东西,这些数据都是 3d 的,但是会被渲染到一个平坦的 2d frame buffer 里;
3、还有许多可以被渲染的单元,例如 Texture、Map 等;
3、GPU 运行的程序叫 Shader,它们会被添加到 GPU 的 command stream,告诉 GPU 应该渲染什么。
4、Shader 有不同的类型,例如负责转换几何大小的 Vertex shader、负责定义颜色和纹理的 Fragment shaders 等
同样分为 Displaying、Rendering、Processing。
fbdev 是传统的 display subsystem,目前已接近被完全淘汰,目前在内核里只有 fb console 还在使用它。
fbdev 存在许多问题:
所有东西都是静态设置、没有 pipeline 的概念、缓冲区是预分配的、不支持热插拔、不支持同步访问等;
现在基本都切换到 drm/kms 这套 display subsystem 了。
drm/kms 的好处在于:
引入了 pipeline 的思想,用面向对象的方式对显示相关的组件进行抽象,将它们封装成不同的对象,这些组件可以独立被配置,并且组合在一起以构成一条完整的 display pipeline。
对上层提供通用的 API (DRM uAPI,u 代表 userspace),所有基于这套 API 的显示应用 (一般是 display server ) 可以运行在不同的硬件平台上。
另外还有一些好处,例如动态分配 frame buffer、提供 Atomic API 以支持同步等。
X 是一个历史悠久的 Linux userspace 显示框架。
经常被提起的X11 (X protocol version 11) ,其实是一个协议,由于它设计比较早,所以并不是很适应现在的硬件和显示需求,因此有了许多针对 X11 的扩展协议,例如 XrandR (用于动态修改显示配置), XSHM (共享内存以避免拷贝), Xinput2, Composite 等。
X11 定义了 client app 如何和 display server 通讯,但是它本身不是 display server ,Xorg 是 X11 的一个实现,所以 Xorg 才是 display server。
X 在显示和输入方面使用的是 driver 的概念,例如 xf86-input-libinput, xf86-video-modesetting (用于 drm/kms), xf86-video-fbdev (用于 fbdev)。
X仍然是在 server 端进行渲染,并且有许多安全问题和功能限制,因此在 PC 和 嵌入式设备上都慢慢地抛弃它了,替代品是 Wayland。
Wayland 是一个更现代的协议,它的出现就是为了代替掉 X,解决 X 所遇到的所有问题。
实现 Wayland 协议的 display server 被称为 Wayland compositors,最出名的实现是 Wayland 官方的 Weston,其他的还有 wlroots 的 sway,GNOME 的 mutter,KDE 的 Kwin。
为了在使用 Wayland 的设备上兼容 X 的程序,还引入了 Xwayland 兼容层。
最后还有一个值得提起的 display server,就是 Android 的 SurFlinger,它是为 Android 深度定制的,基本不可能跑在传统的 Linux 系统上。
另外还有一个叫 display manager 的软件,其实就是登陆界面,它会负责启动 display server 以启动桌面环境。在嵌入式系统中,一般都不需要 display manager。
下面会列举一些与图形相关的库、toolkits、或者是桌面环境。
实现 display server 协议的底层库:
上层应用不会直接使用这些库来开发应用,而是使用 Graphics toolkits。
用于编写 GUI 应用的 Graphics toolkits:
有了 Graphics toolkits 就可以开发出一套完整的桌面环境了,一般会包括::
最后一个要提到的库就是 libdrm:
它是对 DRM uAPI 的封装,它会访问 kernel space 里的 DRM driver。
事实上,如果你不是要写 display server,或者做一些特别硬件相关的活的话,基本不会直接基于 libdrm 写程序,甚至很多内核里写 DRM driver 的驱动工程师也不是很熟悉 libdrm。
嵌入式物联网需要学的东西真的非常多,千万不要学错了路线和内容,导致工资要不上去!
无偿分享大家一个资料包,差不多150多G。里面学习内容、面经、项目都比较新也比较全!某鱼上买估计至少要好几十。
点击这里找小助理0元领取:加微信领取资料
在 kernel space 里,DRM 同时也负责管理 GPU。
但是和显示不同,在应用层并没有一套通用的 API 来访问 GPU,即对于不同 GPU 的 DRM driver,都会提供自己特有的 API 给应用层。这是因为不同厂商的 GPU 的实现都太硬件相关了,很难设计一套统一的 API 来使用这些 GPU。
通常的情况是,在 kernel space 里,GPU driver 只实现最底层的 io 相关功能,例如使用 DRM GEM api 对 Memory buffers (或者叫 buffer object,简称 BO) 进行管理、command stream 的验证与提交,而更核心的活都留给 userspace libraries (例如芯片厂商提供的 libdrm 和 libGLES 之类的,或者是开源社区提供的 Mesa3D ) 去实现。
芯片厂商提供的 GPU userspace libraries 向下会访问 GPU,向上实现通用的 API 以便上层应用进行 3D 渲染,目前常见的 3D 渲染 API 包括:
上面说的是 API,而具体的实现一般有两种形式:
我们重点了解一下开源的 Mesa 3D。
https://docs.mesa3d.org/
Mesa 3D 的特性如下::
再来看一下 2D 的渲染,我们即可以用 CPU 进行 2D 渲染,也可以用 GPU 实现 2D 渲染。
相关的库:
这一块我也不是特别懂,但是为了内容的完整性我就进行简单的介绍吧。
对于 Processing,会有下面几种实现:
相关的库:
到此,关于 Linux 图形显示的框架就介绍完毕了,感谢阅读!
文章链接:
https://mp.weixin.qq.com/s/Jv4MhVpIvTTceYACxiUqVQ
转载自:老吴嵌入式 ,作者吴伟东Jack
文章链接:深夜磨刀,Linux Graphics Stack 概述 | Linux 驱动
页面更新:2024-04-29
本站资料均由网友自行发布提供,仅用于学习交流。如有版权问题,请与我联系,QQ:4156828
© CopyRight 2008-2024 All Rights Reserved. Powered By bs178.com 闽ICP备11008920号-3
闽公网安备35020302034844号