directfbrc文件的使用及参数的详细说明

摘要：
本文主要介绍了directfbrc文件的使用及参数的详细说明，在 directfb应用程序启动做初始化阶段，都会去试图读取该文件。
---------------------------------------------------------------------------------------------------------------------
声 明：
此文为原创，欢迎转载，转载请保留如下信息
作者：聂飞（afreez）
联系方式：[e-mail] （欢迎与作者交流）
初次发布时间：2006-06-06
不经本人同意，不得用语商业或赢利性质目的，否则，作者有权追究相关责任！
-----------------------------------------------------------------------------

directfbrc 是 DirectFB 的配置文件。 它被所有的 DirectFB 应用程序在启动时读取，有 两个这样的文件，一个是存放在 /etc/direcfbrc ，是个全局的，另一个是存放在 $HOME/.directfbrc ，它是个局部的，可以覆盖系统的设置。

需要注意的是，这两个文 件都不是默认存在的，是需要你自己建立的，不要象我一样，刚开始的时候到处找也没有找到，呵呵。

在 directfbrc 使用的参数也可以在命 令行里传递给 DirectFB 应用程序，只需要加上前缀： --dfb:

相关语法：

directfbrc 文件每一行包含一个变量。注释行以井号“ # ”开始，一直到行尾。空行被忽略。

许多参数只是一种开关， 控制着一些特性的开 / 关。这些开关选项有一个 no- 变量，可以关闭相应的特性。下面介绍一些实用的参数和一些默认的参数。

参数：

以下参数可以在 directfbrc 文件中设定

system=<system>

设定使用的图形系统。默认使用 Linux frame buffer (fbdev) ，但你也可以在 SDL （ sdl ）上运行 DirectFB 应用程序。其它的系统在将来可能会被扩展近来。

fbdev=<device>

打开指定的 frame buffer 设备，而不是默认的 /dev/fb0 。

mode=<width>x<height>

设定默认的屏幕显示。如果不设定， DirectFB 将使用 /etc/fb.modes 的第一个设定值。一些 frame buffer 设备 ( 如 vesafb) 不支持模式切换，而只能使 用启动时设定的值。

depth=<pixeldepth>

使用二进制位数设置每像素默认的像素深度。如果没有指定， DirectFB 将使用 /etc/fb.modes 里面的第一个指定的深度值。 DirectFB 支持 8, 15, 16, 24 和 32 位的颜色深度（ color depths ），这些值依赖于 你使用的 frame buffer 设备是否支持。一些 frame buffer 设备 ( 如： vesafb) 根本就不支持模式切换，只能使用在启动时设定的像素深度值。

pixelformat=<pixelformat>

设置默认的像素格式。和上面描述的深度参数类似但允许更精细的控制。 Pixelformat 的值可以为 LUT8, RGB332, RGB16, RGB24 和 RGB32 。一些设备可能还支持更奇怪的 A8, ALUT44, ARGB, ARGB1555, I420, UYVY, YUY2 和 YV12 像素格式。

session=<num>

选择被添加或创建的多应用程序。开始为 0 ，如果强行设置为负值，则使用一个可用的最小值。设定的值将覆盖环境变量“ DIRECTFB_SESSION ”的值。

primary-layer=<id>

选定哪一个层为“主层”（ primary layer ），默认的是第一个。查看‘ dfbinfo ’可以找到你的硬件支持的层列 表。

tmpfs=<directory>

使用给定的文件夹（ tmpfs 挂载点）来多应用程序模式下创建共享内存文件。这个选项只在自动检测失败或者渴望非 tmpfs 存储时才有用。

memcpy=<method>

使用这个选项，对 memcpy() 程序（ routines ）的探测会被忽略，节省了不少启动时间。传递“ help ”参数可以看到一系列的可能值。

quiet

禁止从 DirectFB 控制台（ console ）输出。只显示错误信息。

[no-]banner

启动时使输出 DirectFB 标志（ banner ）有效。默认有效。

[no-]debug

使 debug 输出有效。默认有效，但是除非你编译 DirectFB 时支持 debug 选项，否则，你不会不看到任何错误输出。

force-windowed

强制主表面（ primary surface ）为一个窗口。这样可以使设计成全屏显示的应用程序在一个窗口上运行。

force-desktop

强制使主表面（ primary surface ）成为桌面的后台表面（ background surface ）。

[no-]hardware

置硬件加速为有效。默认会自动探测硬件加速。如果你置它为无效，则显卡驱动虽然也会被加载并可以访问 其它的显示层（如果有的话），但是，所有的图形操作将被软件来渲染（ renderer ）。

[no-]sync

初始化 DirectFB 之前清空所有的硬盘缓冲区（ disk buffers ） 。当你工作环境为实验性的设备驱动和预计会出现冲突（ crashes ）时比较有用。默认此功能为无 效。

[no-]mmx

选相 no-mmx 使得即使检测到有 MMX 的支持也不能使用 MMX 程序（ routines ）。如果提供了 MMX 并在编译时加入了 MMX 的支持，默认该选相有效。

[no-]argb-font

向 ARGB 面载入字的轮廓（ glyphs ），而不是使用 A8 面（ alpha masks ）。该设置使用了更多的内存，但是一些显卡在使用 A8 面时会出现一些诡异现象。如果你的字体看 起来比较奇怪，试试该选项。

[no-]a1-font

向 A1 平面载入字的轮廓（ glyphs ），而不是使用 A8 平面（ alpha masks ）。如果图形驱动不支持彩色 + 混合平移（ blit ，译者注， blit 此处翻译成平移，具体的含义见附录），该选项可以加速字体渲染，但会影响质量。一般情况下你根本不 需要使用该选项，因为基于 A8 字体的软件已经是高度优化和足够快了。

[no-]sighandler

默认情况下， DirectFB 为一些信号量（ signal ）安装了一个可以使应用程序退出的信号量句柄（ handler ）。这个信号量句柄试图在退出 应用程序前解除初始化的 DirectFB 引擎。使用该选项可以开 / 关此特性。

dont-catch=<num>[[,<num>]...]

和上面对 sighandler 选项描述类似。使用该选项你可以对不能使 用该方式被处理的信号量列出一个详细的清单。

[no-]deinit-check

默认情况下， DirectFB 在退出时会检查所有已释放所分配的资源，如果没有，它将在应用程序退出后释放之。该选项可以开 / 关此功能。

block-all-signals

该选项可以阻塞所有的信号量，对 DirectFB daemons 有用（ DirectFB master 应用程序除了 是一个 master 外， 什么也不做）。

[no-]vt-switch

默认情况下， DirectFB 会分配一个新的虚拟终端并转向使用它。

[no-]vt-switching

可以使用 <Ctrl>+<Alt>+<F?> 来切换虚拟终端。这是一个实验特性，经常无效，你看着办吧。

[no-]graphics-vt

使虚拟终端转为图形模式。有如下优点：当 DirectFB 应用程序运行时，内核的消息不会在屏幕上显示。

[no-]motion-compression

DirectFB 常常压缩（ compresse ）鼠标移动事件。也就是 说，一系列的鼠标移动事件被看作一个简单的鼠标移动事件。这样可以达到更快的响应但是鼠标处理的精确度会受到影响。

mouse-protocol=<protocol>

为一个串口鼠标指定使用的协议。以下的协议被支持：

MS 使用微软鼠标协议的两个按钮的鼠标；

MS3 使用扩展的微软鼠标协议的三按钮鼠标；

MouseMan 使用一种 Logitech 开发的另一种扩展的微软鼠 标协议的三按钮的鼠标；

MouseSystems 广泛使用的三按钮鼠标。

串口鼠标所使用的协议的详细信息可参考相关资料。

[no-]lefty

切换鼠标左右按键，对“左撇子”（ ^_^ ）比较有用。

[no-]capslock-meta

把 CapsLock 键映射到 Meta 。对建在 WM 的用户有用，因为键盘上没有 Meta 键（例如 Window 键）。

[no-]cursor

默认情况下， DirectFB 在使用窗口时显示一个鼠标箭头。该选项允许彻底关闭鼠标箭头。即使在应用程序里也不能让它再出现。

disable-module=<modulename>

禁止该模块的载入。模块的名字为文件名，但不能带有 libdirectfb 前缀也不能是其扩展 （例如，若文件名为 keyboard ，则键盘输入模块载入被禁止） 。

bg-none

使背景处理完全无效。不要设置给选项，否则鼠标和窗口移动时会在背景留下难看的痕迹。

bg-color=AARRGGBB

控制背景的颜色。颜色的值为十六进制值。默认的 alpha 值为完全不透明并可能被忽略。例如，设定背景色为红紫色（ magenta ），可以使用 bg-color=FF00FF 。

bg-image=<filename>

使用给定的文件中的图象充填背景。图象会被伸缩（ stretch ）以适应屏幕的尺寸。

bg-tile=<filename>

类似 bg-image ，这里使用图象的图快（ tile ）方式在屏幕的尺寸显示，而不是伸缩方式。

[no-]translucent-windows

默认情况下， DirectFB 窗口可能是半透明的。如果你使该选项无效，则窗口会被强制为完全不透明或者是全透明。当你的显卡不 支持 alpha 半 透明图快（ alpha-transparent blit ）时，该选项比较有用。

videoram-limit=<amount>

限制 DirectFB 使用的视频 RAM 。视频 RAM 大小的单位为 K 字节数。

matrox-tv-standard=[pal|ntsc]

控制由 Matrox 卡的 TV 输出产生的信号。

[no-]matrox-sgram

一些老的 Matrox G400 卡有 SGRAM 并且如果设定该选项，一些图形操作在这些卡上执行相当快。如果你的卡上没有 SGRAM ，不要试图选中该选项，否则，你 不得不重起。

[no-]matrox-crtc2

如果你有个双重的 head G400/G450/G550 ，你可是使用该选项利用第二个 head 驱动附加层。

screenshot-dir=<directory>

如果选定该选项，当你按下 <Print> 键， DirectFB 将把屏幕的内容以 PPM 格式放到这个指定的目录。

window-surface-policy=<policy>

控制窗口平面存放的位置。 <policy> 的值可以是：

auto DirectFB 依据硬件特性自动判断，默认为该选项；

videohigh 以高优先级方式切换（ swap ）系统 / 视频内存；

videolow 以低优先级方式切换（ swap ）系统 / 视频内存；

systemonly 窗口平面保存在系统内存中；

videoonly 窗口平面保存在视频内存中。

desktop-buffer-mode=<mode>

控制桌面缓冲区模式。无论何时，窗口在移动、打开、关闭、调整大小或者变换内容， DirectFB 将在受影响的范围内重新 合成窗口堆栈，这是通过和平移（ blit ）在该范围的窗口一起来完成的。不通明窗口被直接平移，而半透明的窗口则使用 alpha 混合或颜色键来平移。如果有后 端缓冲区（ back buffer ）的话，合成是不可见的，因为只有最终的结果会被拷贝到前端缓冲区（ front buffer ）。如果没有后端缓 冲区，合成的每一步都是可见的，这将导致明显的闪烁，除非所有的窗口都是非透明的。

<mode> 的可选值有：

auto DirectFB 依据硬件特性来判断，为默认值。如果硬件支持简单 blit （从后端向前端缓冲区中拷贝）操作， DirectFB 会在视频缓冲区中选取一个 后端缓冲区。如果没有加速功能，会在系统内存中开辟一个后端缓冲区，因为这样软件里的 alpha 混合合成操作可以执行地更好，并可以避免在结果已经拷贝到前端缓冲区中的情况下，再重新从视频缓冲 区中读取。

backsystem 在系统内存中开辟一个后端缓冲区。如果你的硬件支持简单 blitting 但却没有 alpha 混合，这是推荐选择，你将得到许 多 alpha 混合 窗口。

backvideo 在视频内存中分配前端和后端缓冲区。该值特别不建议设定，因为如果 blit 被加速的话，‘ auto ’模式下会选择该值。没有加速的 blit 操作，该值不推荐使用。

frontonly 没有后端缓冲区。如果你仅仅使用不透明窗口并且不使用任何颜色键，这是一个最佳选择。

vsync-after

flip 操作后等待垂直折回（ vertical retrace ）。默认 情况下在做 flip 操 作前等待。

vsync-none

对垂直折回（ vertical retrace ）关闭 polling 操作。

例子

下面的例子说明了怎么在 命令行模式下，把上面介绍的参数传递给 DirectFB 应用程序。

df_neo --dfb:no-hardware

以没有硬件加速的方式开始运行 df_neo

df_neo --dfb:help

列出可以传递给 df-neo 的所有可选参数。

附录：

说明，这里以下的部分是从网上摘录的，仅供参考！

Blit 操作相关解释（从网络摘抄整理，详见参考文献，即 reference ）：

基 本含义：

其意义是将一个平面的一部分或全部图象整块从这个平面复制到另一个平面；

Blit 与 CopyBox 的区别：

Blit 用于在不同的屏幕设备 ( 物理的或者内存的 ) 之间拷贝一块像素点， CopyBox 则用于在同一屏幕上实现区域 像素的拷贝。如果使用的是线性模式， Blit 的 实现非常简单，直接 memcpy 就可以了，而 CopyBox 为了防止覆盖问题，必须根据不同的情况，采用不同的拷贝方式，比如从底到顶底拷贝，当新老位置在同 一水平位置并且重复时，则需要利用缓冲间接拷贝。如果使用平面显示模式，这里就比较复杂了。因为内存设备总是采用线性模式的，所以就要判断是物理设备还是 内存设备，再分别处理。这也大大地增加了 fbvga16 实现的代码。

Blit 与显示内存的有效利用

新的 GAL 接口能够有效利用显示卡上的显示内存，并充分利用硬件加速功能。我们知道，现在显示卡一般具有 4M 以上的显示内存，而一般的显示模式 下，不会占用所有的显示内存。比如在显示模式为 1204x768x32bpp 时，一屏象素所占用的内存为 3M ，还有 1M 的内存可供应用程序使用。因此，新的 GAL 引擎能够管理这部分未被使用的显示内存，并分配给应用程序使用。这样，一方面可以节省系统内存的使 用，另一方面，可以充分利用显示卡提供的加速功能，在显示内存的两个不同内存区域之间进行快速的位块操作，也就是常说的 Blitting 。

Blitting 操作与嵌入式汇编代码优化处理

在上层 GDI 接口在建立内存 DC 设备时，将首先在显示内存上分配内存，如果失败，才会考虑使用系统内存。这样，如果 GAL 引擎提供了硬件加速功能，两个不同 DC 设备之间的 Blitting 操作（即 GDI 函数 BitBlt ），将以最快的速度运行。更进一步，如果硬件支持透明 或 Alpha 混和功能，则透明的或者 Alpha 混和的 Blitting 操作也将以最快的速度运行。新的 GAL 接口能够根据底层引擎的加速能力自动利用这些硬件加速功 能。目前支持的硬件加速能力主要有：矩形填充，普通的 Blitting 操作，透明、 Alpha 混和的 Blitting 操作等。当然，如果硬件不支持这些加速功能，新的 GAL 接口也能够通过软件实现这些功能。目前通过 GAL 的 FrameBuffer 引擎提供上述硬件加速功能的显卡有： Matrox 、 3dfx 等。

在通过软件实现透明或混和的 DC 间 Blitting 操作时，新的 GAL 接口利用了两种有效的优化措施：

在 i386 平台上，充分利用嵌入式汇编代码进行优化处理；比如在处理 32 位色模式下的普通 Blitting 操作时，在利用普通的 C 库函数，即 memcpy 进行位块复制时，由于 memcpy 函数是以字节为单位进行复制的，从而无法利用 32 位 CPU 对 32 位字的处理能力，为此，可以使用嵌入式汇编，并以 32 位字为单位进行复制，这将大大提高 Bliting 操作的处理速度。

对源 DC 进行 RLE （ Run Length Encoding ）编码，从而对象素的处理数量最小化。 RLE 可以看成是一种图象压缩算法， Windows BMP 文件就利用了这种算法。 RLE 是按水平扫描线进行压缩编码处理的。在一条扫描线上，如果有大量相 同的象素，则不会保存这些象素点，而是首先保存具有相同象素点的数目，然后保存这些象素点的值。这样，在进行透明或者混和的 Blitting 操作时，可以大大降低逐点运算带来的速度损失。 但是，如果在最坏的情况下，比如所有水平扫描线上的象素点都具有和相邻点不同的象素值，则 RLE 编码反而会增加象素的存储空间（最坏的情况是原有空间的两倍），同时也会降低 Blitting 操作的速度。因此是否使用 RLE 编码，要根据情况而定。新的 GDI 接口在指定源 DC 的透明和 Alpha 通道值时，可以指定是否使用 RLE 编码。