xorg的未来
看到大家对xorg存在很多的误解和迷惑，下面是我个人的理解
下面都是很简单的问答的形式，力求简单的回答一些常识性的问题,说多了倒还难以理解了。
dri
关于dri，这个是xfree86 4.x就出来了，
主要是用来加速本地应用。现在的机器基本上都是自己用了，关于glx，dri怎么实现的，从底下硬件，到上面driver到xorg，到应用程序怎么工作的，需要一大篇专门的文章来讲
不适合放在这里了。无论dri还是dri2都是类似的，至于drm是什么，drm是实现dri这个框架，需要内核的支持，这个部分就是内核那个部分的东西了。主要是资源管理，锁管理
这些了。光dri这里需要很长的文章来讲，dri实际上可以看作一个中间层，所有的人都通过dri来操作资源，xorg一样。当然client可以是xorg也可以是其他的程序
xorg可以和硬件剥离开了。
xaa/kaa/exa/uxa
xaa是传统的加速框架了。很多基本操作的接口都留出来有硬件加速的接口。但是后来有人研究发现，只需要加速很少的函数就可以了。
所以就有了kaa，
kaa
kaa本来是kdrive使用的，Kdrive Acceleration Architecture
什么是 kdrive. kdrive是xserver的一种，有人觉得xfree86太庞大了，所以就有了kdrive，开始的时候叫tinyx，
不同的xserver在代码里面是不同的目录树，都存放在hw下面。
ailantian@vax:~/soft/xorg/temp/xorg-server-1.6.0$ tree -L 1 hw
hw
|-- Makefile.am
|-- Makefile.in
|-- dmx
|-- kdrive
|-- vfb
|-- xfree86
|-- xnest
|-- xquartz
`-- xwin
7 directories, 2 files
ailantian@vax:~/soft/xorg/temp/xorg-server-1.6.0$
xfree86就是xorg的版本了，kdrive下面存放的都是kdrive的代码了。编译完之后就会放在kdrive/src/下面了，编译完成叫Xfbdev.
exa
exa是大家认为kaa这个框架很好，所以移植过来放到了xorg里面，改了个名字叫exa，给xorg用的，当然需要xserver和驱动两方面的工作，
对于xorg这边实现的exa，代码在hw/xfree86/exa/下面，驱动里面会注册这些函数，当调用gc的绘图的函数的时候就会判断驱动是否支持
硬件加速，如果支持就会使用硬件的，所谓的xf86-video-xxx这样的驱动，基本都是exa的实现了，部分还会提供xaa的实现。
uxa
uxa是intel在exa的基础上改了一些东西过来的，现在被抛弃的应该说。在intel这个版本的驱动里面有uxa的实现，和exa基本相同
ailantian@vax:/mnt/sdb1/ubd/soft/xorg/temp/xf86-video-intel-2.6.99.902$ ls
acinclude.m4 autogen.sh configure.ac COPYING cscope.files cscope.out Makefile.am man README src uxa
ailantian@vax:/mnt/sdb1/ubd/soft/xorg/temp/xf86-video-intel-2.6.99.902$
关于xvideo
现在xvideo不是和berly,compiz等等在一起的时候就会闪吗，
比如上面的文章就说到用dri2就可以了，实际上根本原因是现在xvideo的实现，一般来说第一个port都是使用overlay来实现的。
这里又涉及到显卡的硬件了，各家的硬件是五花八门，所以xorg的驱动这里也是很乱，架构也很乱，想统一起来比较困难。这个单开一个标题来说。
目前的显卡基本都是支持3d的，新的显卡是只有3d没有2d的，xvideo这里本来也是可以用texure来实现xvideo，用tuxture来实现xvideo的话
是不会有这个问题的。一般现在的显卡，比如ati的driver，第一个port是overlay，剩下的15个port都是用tuxture来实现的。
用这种port的xvideo来播放视频，然后与composite来一起工作是没有问题的，compiz/berly都是用的composite了。
Xvideo的设计初衷是为了快速的显示图片视频，所以结果是直接输出到屏幕的，这样减少周转，但是和composite的设计就背离了。
Xvideo的硬件加速框架比较简单，不过还是需要专门的一篇文章来讲解。
xvideo这边就目前来说，好像很多接口都已经没有人用了，用的就是XvPutImage,因为Video本身来说解码完成之后就是一帧一帧的数据。
到最后的目的无非就是要把这个frame显示到屏幕上面，中途copy越少越好，能够用到硬件加速就好，硬件的实现多种多样，但是基本的要具备
格式转换，比如yuv->rgb，因为我们的屏幕是rgb的，但是mpeg4或者h264等等解开一般都是yuv格式的，当然yuv格式又分成很多种，硬件不一定
都支持，这个时候就需要软件转换，这个就是copyplanerdata或者copypackedata的工作了，他们都是用来封装数据的，把数据封装成硬件所支持的方式
然后就交给硬件去显示,还有另外一个基本的功能，自然就是缩放了，比如视频原始的分辨率是800x600,但是我们要全屏播放的时候就需要放大，
gpu其实很容易完成这个功能的。无论是pc级别的显卡，还是现在application processor里面的图形加速单元，或者MDP(mobile display processor)
都能轻松的完成这样的工作，这个如果用cpu来算，速度会慢的出奇，当然这个硬件加速需要另外专门的文章来讲，因为解码编码这里需要很多的硬件资源。
各个流程之间的有可以整合的地方，以便让系统发挥最大的性能优势。
关于composite
Xomposite是一Xserver的一个扩展
composite可以完全用软件来实现，比如metacity，xfwm，等等现在基本都可以自己支持composite了，composite下面实际上也可以调用硬件加速，
比如metacity的实现是使用的Xrender。XrenderComposite实际上这个跑到驱动里面去的话，如果有exa就会调用到exapreparecomposite,checkcomposite
composite,donecomposite这些实现，如果要加速composite的话，就需要实现这些exa的扩展了，
composite的运作机制，实际上所有的画面都是先离屏画的，也就是说画在一块内存/显存里面，这块内存是不直接显示的,然后到最后把所有的窗口做alpha blending
然后才显示到屏幕上面，这样我们就可以看到透明效果了。
composite为什么打开之后系统变慢？原因很明显，因为所有的画图结果都不能直接显示到屏幕，要先画到后台，然后windowmanager把当前所有window的buf
做alpha blending之后才显示出来，本身这个框架就导致延迟，然后就是alpha 运算本身很慢了。
关于exa和Xrender的关系
说简单一点就是Xrender是对上层应用的接口，上层的程序都是Xlib写的，可以发起Xrender的请求，他们看到的都是Xrender的接口，当然这个是如果你想用Xrender
这个扩展的话，比如cairo，他绘图的时候就可以选择很多的后端，比如Xlib这个后端使用的就是Xrender,cairo还可以使用很多其他的后端，比如glx(使用的是glitz)，
clutter
clutter这个东西是一个做程序的库，可以用3d来做2d的程序，让2d的程序有一些很库的效果，其实就是做动画。如果还是不明白就想想flash做的游戏就可以了。
这个东西其实本来就是做animation用的，所有的东西都可以比对电影，比如timeline,比如actor,比如stage。clutter也有很多不同的后端,比如xlib
比如egl(使用的是opengles1.1或者2.0)或者eglx（使用的是egl+eglx的实现）
cairo
这个东西是一个2d矢量库，用来做2d的矢量图的，比如我们以前画图像tc里面，就会有lineto,moveto,现在cairo看起来也是一样的，不过cairo画出来的是矢量图。
也就是说在画的时候算的。而不是像素的图，如果是像素图的话，放大就会很不清楚了。而矢量图如果放大，实际上就是需要重新算，然后生成一个新的图片，
比如圆，初始半径是5,放大之后，它会重新画一个半径是10的圆，如果实在不清楚，就google一下矢量图和位图的区别。cairo是可以使用
gallium3d
这个东西是mesa的最新发展，主要是解决3d加速的问题了。因为xorg的历史悠久，远远老于linux了，从最早的时候来说，显卡应该是没有任何硬件加速能力的，
我没有见过那么古老的东西，不过sm501这样的多媒体协处理器可能比较像早期的显卡吧，不过好歹sm501还有一些硬件加速，算是2d的。后来慢慢发展显卡有了2d加速单元
就类似sm501了，再后来显卡支持了3d加速，就是离我们不远吧，我们这代人可能没用过有2d加速单元的显卡，好像都是3d的，再后来显卡就只有3d加速单元了，无非
2d是3d的一个特例。到现在显卡支持更多的功能，比如shader，比如硬件解码高清等等。一些人立志改变这种状况，但是实际上这些东西都是商业公司在推动，如果
没有商业公司的支持，就不可能发展了，当然另外一个方面是他们自己要用，开放出来有更多的人来看代码，debug，还有就是3d这里的框架本身就比较复杂了，就算开放出来
大家也还是需要一段时间来理解他们到底是怎么设计的，因为要按照这样的框架来开发驱动。目前支持intel，amd，这些开源的驱动。
就目前的理解来说，无论用什么来操作，比如directx，或者opengl，或者opengles，或者openvg，或者shader，或者其他的，无非都是画一块缓冲区。
然后后来输出如果是xorg，那么就调用xputimage去输出这个缓冲区，xorg这边因为有exa的加速，所以也可以很快的输出,xorg就不会去管理3d的任何东西了，
很多人一直想让xorg的工作更加单纯，只是管理这些窗口，clip region等等。不要搞的和硬件相关。gallium3d的发展趋势来说，看起来是想统一图形加速这一块
无论是3d加速还是2d加速。
目前2d/3d加速的框架
目前用的最多的还是2d使用exa，3d使用dri,当然，exa这边也可以使用dri来实现，所以到最终做事的还是dri这个框架。这样就统一到dri了。
无论是dri还是dri2
硬件加速的实现
硬件加速无非就是写寄存器了。数据传递了，这些。由于硬件实现的不同，对应用程序提供的接口也不同，
大家可以多看看开源的驱动就知道这些东西到底是怎么工作的了。
Xgl的失败
Xgl已经废弃了。个人感觉失败应该说是必然的。
xgl是基于kdrive的，这个的东西更新的相对来说很慢，xorg的代码更新的很快，导致kdrive有些功能已经不能使用，连基本的鼠标处理流程都有问题了。
driver的问题，nvidia等厂家在xds的时候已经明确说明这种框架会导致dual port的驱动很难开发。而xgl的初衷就是为了让这些硬件厂家给linux提供高质量的opengl的driver
这个根本就没有达到
glitz这个东西本来现在是只能使用opengl,而opengles的接口做的很差劲
本来这个东西novel开始是闭源开发的。后来可能是不行所以开源了，然后后来xgl就转向了嵌入式dri/egl这边，但是mesa的egl的扩展一直没有得到驱动厂商的支持，
这样导致两边都不行。
从设计上来说xgl的所有的绘图操作都是使用glitz的，但是glitz本身就是新开发的东西，那个时候未程序，而kdrive自己也有很大问题，而mesa/egl这边也是刚开始做。
基本没有一个东西是可用的,另外xgl自己也是新设计的东西，从头开始实现的。
xgl下面的所有操作都是用glitz，所以就不存在所谓的2d加速了(没仔细研究).因为所有的东西都是走的GL,因为现代的显卡都只有3d加速单元和硬件视频解码单元了，
嵌入式application processor除外。
aiglx
这个东西，感觉没什么用，现在虽然已经成为了标准的glx loader。但是好像就是为了berly/compiz这样的应用而存在的,需要mesa也做扩展。为了好看，就要多做很多工作。
framebuffer
本来显卡比如有512M的显存，但是只有一块显存是对应到我们的屏幕的。这个就是framebuffer了，
没仔细看代码，按理说/dev/fb这个抽象出来的设备应该就是把这块内存抽象成这个设备，然后用户空间可以mmap访问了。
KMS
现在能够操作显卡的程序太多了，而且彼此不知道对方在干什么，比如framebuffer的driver就不知道xorg的driver在干什么，
所以开机的时候framebuffer的驱动初始化，显示东西，然后等到启动xorg的时候这个过程还要再来一遍，等到我们使用ctrl+alt+fx的时候又要关闭xorg这边回到console
其实这个只要做一次就行了，所以有了kms。设置显卡的mode只通过唯一的接口，当然这样会导致操作fb的driver要改，比如目前的framebuffer框架要扩展一下，intel又走在前面
了，毕竟是开源的驱动。然后就是xorg的driver也要改一下，因为xorg不需要做那么多工作了，还有就是内核当然要提供这些kms的接口了。
暂时就说这些吧，硬件加速的实现之后在慢慢写。讲讲kaa硬件加速和xvideo的硬件加速的实现。xorg+exa原理上来说差不多的。
需要一些图片说明:)
国内做xorg或者kdrive相关的文章很少，硬件加速的实现就更少了，想分享出来大家一起学习。
阅读(3083) | 评论(1) | 转发(0) |
