Framebuffer,Xorg,directFB,openGL,QT,GTK关系

本文待整理！！！

问：Xserver使用的是Framebuffer吗？

答：Xserver有多种实现，如Xfree86、Xorg等，Xfree86默认不采用Framebuffer；而对于Xorg，可以根据xorg.conf里的配置判断

如

-Section "Device"                                                           
-        Identifier      "Configured Video Device"                          
-        Driver          "fbdev"                 
-EndSection

其中的fbdev表示使用Framebuffer画图，需要内核的支持(2.2以上内核)和相应的framebuffer驱动， framebuffer驱动与硬件相关，可由显卡硬件厂商提供(如vpmfbDrv.ko),也可用xorg提供的通用的FB驱动：xserver-xorg-video-fbdev，它是基于内核里的fbdevhw(fbdevhw - os-specific submodule for framebuffer device access,将显卡的硬件相关操作已经封装了，它也可以被其他的video drivers使用)

   http://www.linuxgraphics.cn/xwindow/xorg_hardware_accelerate_cont.html   Xorg 嶄新的硬體加速與效能提昇機制(续)    非常好的图！！！opengl、xorg、直接渲染、间接渲染  、总图！！！

http://liyanrui.is-programmer.com/2009/2/8/glx-notes.7061.html

直接渲染、本地渲染：

相关好文章记录：

http://lp007819.wordpress.com/2010/11/19/%E5%85%B3%E4%BA%8Eglx-direct%E5%92%8Cindirect-rendering/     是否支持3D图形和direct ,indirect rendering 没有任何关系。事实上它与3D硬件加速也没有关系。  有图    这里的硬件加速应该是2d的情况，对于3d的情况，必须是直接渲染才行！（个人猜想）

http://liyanrui.is-programmer.com/2009/2/8/glx-notes.7061.html   

GLX 与显卡驱动

为了取得广泛的平台支持，OpenGL 是不依赖任何窗口系统的，但是我们使用 OpenGL 绘制的三维场景却需要嵌入在某种窗口程序中才可以为人所见。似乎也是约好了的，目前主流的窗口系统（X Window, MS Windows, Mac OS）只是提供了完善的二维图形交互环境，而将复杂的三维图形渲染任务交给 OpenGL （MS Windows 更热衷于用 Direct3D 来取代 OpenGL）。当 OpenGL 与窗口系统们达成了相互依存的默契之后，便出现了用于衔接 OpenGL 与窗口系统的扩展库，这些扩展库的主要目标就是实现 OpenGL 图形与对应窗口画面之间的转换。GLX 库解决了 X Window 中的 OpenGL 图形渲染问题。同样的，WGL 和 AGL 库分别解决了 MS Windows 和 Mac OS 窗口系统中的 OpenGL 图形渲染问题。

GLX 像胶水一样，建立了 X Window、OpenGL 以及 3D 硬件加速驱动之间的联系。在 Linux 中，如果未有安装相应的支持 3D 加速的显卡驱动，那么 GLX 可以调用 Mesa (Unix-like 系统中应用最为广泛的 OpenGL 实现) 的 3D 软件加速来取得 X Window 与 OpenGL 的集成；当然，这种做法所实现的 3D 渲染效率就要大打折扣，并且也会累的 CPU 气喘。多了解一下 X Window 是如何驱动硬件 3D 加速，可以更加深刻的理解 GLX 的工作机理。不过，目前这方面的文档实在太少了，下面文字是我个人的一些猜测，未必正确。

目前，Nvidia 和 ATI 这两大主流显卡均面向 Linux 提供了驱动程序，但是它们的做法不相同。Nvidia 驱动提供了自己的 GLX 库，在安装驱动时，会替换掉 X Window 的标准 GLX 库，另外也会将 Mesa 提供的并且只具备 3D 软件加速支持的 libGL 库替换为自己的 libGL 库。Nvidia 驱动还会提供一个 Linux 内核模块，这样可以让 X Window 通过内核访问显卡的帧缓冲区。与 Nvidia 驱动相比， ATI 则显得比较规范（此处不论其驱动的质量优劣），它利用 DRI + Mesa 来实现 3D 硬件加速，而不是像 Nvidia 驱动那样，什么都是自己去实现。最近，ATI 的开源 3D 加速驱动也渐渐浮出水面，以后买显卡，得多考证考证 ATI 了。

直接渲染与间接渲染

GLX 所支持的 OpenGL 三维图形渲染分为直接渲染与间接渲染，其区别如下图所示：

这里，勿将直接渲染与“硬件加速”的概念混淆了。无论是直接渲染还是间接渲染，都可以利用硬件加速，当然前提是显卡驱动要提供硬件加速支持。同样，也不要将间接渲染与“软件加速”的概念混淆。直接渲染，可以简单理解为本地渲染，即在同一台机器上的 X Client/Server 环境中实现三维图形渲染；相应地，间接渲染可以理解为远程渲染，也就是在网络环境中实现三维图形硬件加速渲染。

http://wiki.linuxquestions.org/wiki/Framebuffer

A framebuffer is a block of memory that holds one frame (one whole display or picture) of pixel data.

In the Linux kernel, there is a framebuffer device available. This device provides a hardware independent API for graphics devices. Applications see a framebuffer and can manipulate it though this API. It is accessed through a special device, normally /dev/fb* (e.g. /dev/fb0). It behaves much like othermemory devices in linux, in that you can also read and write it with normal tools. For example copying the framebuffer to a file (effectively making a raw screenshot) can be done with:

cat /dev/fb0 > somefile

The main application of this in the Linux kernel is allowing the Tux logo at boot and a high resolution text console (a "Framebuffer console" -- the module for this is called fbcon). It's also for use on platforms which don't support a standard text mode. Other applications can also use it to get graphics without X or some other library, this is especially interesting for embedded devices.

Drivers

These drivers are normally located in kernel/drivers/video. There are general drivers, like vesafb (which supports VESA BIOS extensions 2.0 capablevideocards) and vga16fb (VGA compatible videocards). There are also different ones for specific videocards/chipsets (which do some basic 2D hardware acceleration to make it faster -- most of the hardware acceleration is left to do by the applications that use it).

Try

modprobe -l | grep fb

to see a few on your system.

Configuring framebuffer console

• Kernel boot parameters, vga=ask and friends
• fbset
• video modes
• etc

XFree86

XFree86 can also use the Linux framebuffer device. There is a special XFree86 driver, called fbdev, which uses the framebuffer device. This allows XFree86 to support even more videocards (specially with the vesafb). Note however that this driver is un-accelerated, meaning it doesn't make use of specific extra graphics hardware on your video card, so graphics rendering can be slow. Many other XFree86 videocard drivers can also use the Linux framebuffer device (without losing hardware acceleration). This is done by adding:

Option "UseFBDev" "True"

to the Device section of the XF86Config file. Check the manual page of the XFree86 driver to see if it supports this. There isn't a difference in performence between using the framebuffer device and not. The difference lies in the implementation of the driver (using the fbdev device moves videomode and colormap handling into the kernel). So it's mainly a developer thing -- users normally don't care. It just makes XFree86 use a 'clean' API to access the hardware, instead of it's own code that directly accesses the hardware.

Other applications

There are many other applications that can use the framebuffer device. Some of these are:

• SDL can also output to it (so every application using SDL can theoretically run on it)
• MPlayer can use it to display videos directly on the linux console.
• DirectFB - A library which is a layer on top of the linux framebuffer device which does hardware acceleration, windowing, and input
• GGI - It also has a output target for this

3D hardware acceleration

There are also some projects with the goal of adding 3d hardware acceleration to the linux framebuffer device.

• fbdev/DRI driver from mesa3d
• DirectFB

Other Docs

http://www.linux-ren.org/modules/wordpress/?p=1043   关于framebuffer的一些疑问

http://wdqfirst.blog.163.com/blog/static/1133474112009101925223720/

xorg架构 将来 以及一些基本常识浅析（很多概念解释）

http://blog.sina.com.cn/s/blog_537bca2a0100ekhi.html            

FB调研

 (2009-08-11 09:10:56)

  

QT分为3层次：

上层控件：QWidget类是所有用户界面对象的基类，而QWidget继承QPainterDevice。

上层图形：QPaintDeviceMetrics 描述paint device 的信息。QPaintDevice 封装 paint device。QPainter 封装绘图操作。

这2层都是和系统、硬件无关的。因此也看不到FrameBuffer存在。

最后是图形引擎：QGfx 封装了对FrameBuffer的绘图操作，是低级别的QPainter。QScreenCursor 在 QScreen 上绘制鼠标光标等。QScreen 在Qt/Embeded里封装了FrameBuffer的显示设备。

在QT中，真正关心硬件操作的是图形引擎层。

 

图形引擎实现方式在linux上有多个：

1、  通过X11

2、  DFB

3、  LinuxFB

其中桌面PC的QT版本是通过X11，也可选择DFB。DFB最终也是通过FrameBuffer驱动实现。但是在QT embedded版本中，只能使用linuxFB，也就是FrameBuffer驱动。如下图：

 

对于图形输出，qte的缺省行为是每一个widget会把自己画在一块内存中，然后由Server负责把这快内存copy到Linux的Framebuffer上去。

PC版本的QT client应用程序，可以直接输出数据到Framebuffer上面去。有两种方法可以实现这一点，第一种是为每一个Widget都设置Qt::WA_PaintOnScreen属性，另一种是QDirectPainter。WA_PaintOnScreen方式只是不使用双缓冲的模式，实际就是让Xorg马上刷入FrameBuffer。而QDirectPainter，看了一下实现，同样在QDirectPainter对象初始化时，连接显示设备的函数中打开/dev/fb0的设备，也就是FrameBuffer。

 

另外尝试查找OpenVG的代码，发现OpenVG还是属于比较新的领域，真正实现的linux开源代码较少。而且大部分是通过Opengl实现的，Opengl的驱动部分代码也不好找。翻阅了部分资料，了解到：

Linux显卡驱动包括两块：一个是内核下的控制显卡指令和显卡framebuffer。

Opengl加速在PC通过2个方式：

1、Xorg上的DRI硬件加速驱动方式

2、通过libdrm传递显示数据和硬件绘图指令。操作libdrm，Opengl库就可以绕过Xorg进行加速。

无论是通过直接控制显卡指令，还是通过显卡FrameBuffer，它们必须先了解显卡类型及是否具备硬件功能。而这部分实现也正是FrameBuffer驱动功能之一。

 

在OpenGL ES层次，可能同时与FrameBuffer和加速硬件打交道。关于Linux的FrameBuffer驱动，提供接口给上层调用，而不是直接操作硬件的原因。个人认为：

FrameBuffer设计初期并没有考虑硬件加速的可能性，导致不同显卡厂商通过不同的手段实现加速功能。DirectFB也做一部分API的统一工作，使应用摆脱对硬件的直接操作，而由它进行统一管理。这也使得DFB维护工作量较大， 对于新出的显卡不得不做新的gfx适配层。因此，到了新的加速功能OpenVG、OpenGL标准制定后，要在Linux上运行，必须找一个通用的代理者——Xorg。但是Xorg体积太大，不适合嵌入式设备。而Xorg实际也离不开FrameBuffer，那么对于OpenGL ES这类PC转向嵌入式的，只能同时具备FrameBuffer和加速硬件的访问功能。

对于windows，微软较早就确定了DX的结构，所有显卡驱动不得不实现标准接口的硬件操作。因此上层应用只需与DX交互，而不需要用户态操作硬件。

用户态驱动一般而言，适合数据量不大的、简单的输入输出设备，这对于应用程序较为方便。对于GPU是否存放在用户态，可以再进一步评估。但如果应用只是为了保证GPU context唯一，提升速度的话，并不需要在用户态操作硬件。可以如某些加速引擎那样，引擎内部尽量做到保证context唯一。否则应用之间的耦合程度较高，可维护性降低。

http://blogold.chinaunix.net/u1/40978/showart.php?id=2286768    Xorg 硬件加速 常用术语  很长

http://garfileo.is-programmer.com/2011/4/3/opengl-support-for-gtk+-3-0-with-glx-in-x11.25812.html  

上述过程中的三个主角分别是：X11、GLX 和 OpenGL。它们之间的关系可以理解为：一个 OpenGL 牌子的相机把现实中的图像影印为底片，一个叫做 GLX 的洗照片的人在暗房里将底片处理为相片，然后一个叫做 X Window 的家伙为相片做了个相框（事实上，X Window 是个相框公司的老板，他本人不负责制作相框，而是交给手下的工人，也就是那些被称为“窗口管理器”的家伙们，例如 metacity、mutter、compiz 等等，由他们来制作相框）。

 wiki:opengl硬件加速本质    http://en.wikipedia.org/wiki/Framebuffer

As the demand for better graphics increased, hardware manufacturers created a way to decrease the amount of CPU time required to fill the framebuffer. This is commonly called a "graphics accelerator" in the Unix world.

Common graphics drawing commands (many of them geometric) are sent to the graphics accelerator in their raw form. The accelerator then rasterizes the results of the command to the framebuffer. This method can save from thousands to millions of CPU cycles per command, as the CPU is freed to do other work.

While early accelerators focused on improving the performance of 2D GUI systems, most modern accelerators focus on producing 3D imagery in real time. A common design is to send commands to the graphics accelerator using a library such as OpenGL. The OpenGL driver then translates those commands to instructions for the accelerator's graphics processing unit (GPU). The GPU uses those microinstructions to compute the rasterized results. Those results are bit blitted to the framebuffer. The framebuffer's signal is then produced in combination with built-in video overlay devices (usually used to produce the mouse cursor without modifying the framebuffer's data) and any analog special effects that are produced by modifying the output signal. An example of such analog modification was the anti-aliasing technique used by the 3dfx Voodoo cards. These cards add a slight blur to output signal that makes aliasing of the rasterized graphics much less obvious.

Popular manufacturers of 3D graphics accelerators are Nvidia and ATI Technologies.