当前位置：文档之家 › Framebuffer的配置及应用

Framebuffer的配置及应用

  • 格式：doc
  • 大小：251.00 KB
  • 文档页数：45

Framebuffer的配置及应用*一、FrameBuffer的原理*FrameBuffer 是出现在 2.2.xx 内核当中的一种驱动程序接口。

Linux是工作在保护模式下，所以用户态进程是无法象DOS那样使用显卡BIOS里提供的中断调用来实现直接写屏，Linux抽象出FrameBuffer这个设备来供用户态进程实现直接写屏。

Framebuffer机制模仿显卡的功能，将显卡硬件结构抽象掉，可以通过Framebuffer的读写直接对显存进行操作。

用户可以将Framebuffer看成是显示内存的一个映像，将其映射到进程地址空间之后，就可以直接进行读写操作，而写操作可以立即反应在屏幕上。

这种操作是抽象的，统一的。

用户不必关心物理显存的位置、换页机制等等具体细节。

这些都是由Framebuffer设备驱动来完成的。

但Framebuffer本身不具备任何运算数据的能力,就只好比是一个暂时存放水的水池.CPU将运算后的结果放到这个水池，水池再将结果流到显示器.中间不会对数据做处理. 应用程序也可以直接读写这个水池的内容.在这种机制下，尽管Framebuffer需要真正的显卡驱动的支持，但所有显示任务都有CPU完成,因此CPU负担很重.framebuffer的设备文件一般是 /dev/fb0、/dev/fb1 等等。

可以用命令: #dd if=/dev/zero of=/dev/fb 清空屏幕.如果显示模式是 1024x768-8 位色，用命令：$ dd if=/dev/zero of=/dev/fb0 bs=1024 count=768 清空屏幕；用命令: #dd if=/dev/fb of=fbfile 可以将fb中的内容保存下来；可以重新写回屏幕: #dd if=fbfile of=/dev/fb；在使用Framebuffer时，Linux是将显卡置于图形模式下的．在应用程序中，一般通过将 FrameBuffer 设备映射到进程地址空间的方式使用，比如下面的程序就打开 /dev/fb0 设备，并通过mmap 系统调用进行地址映射，随后用 memset 将屏幕清空（这里假设显示模式是 1024x768-8 位色模式，线性内存模式）：int fb;unsigned char* fb_mem;fb = open ("/dev/fb0", O_RDWR);fb_mem = mmap (NULL, 1024*768, PROT_READ|PROT_WRITE,MAP_SHARED,fb,0);memset (fb_mem, 0, 1024*76;FrameBuffer 设备还提供了若干ioctl命令，通过这些命令，可以获得显示设备的一些固定信息（比如显示内存大小）、与显示模式相关的可变信息（比如分辨率、象素结构、每扫描线的字节宽度），以及伪彩色模式下的调色板信息等等。

通过 FrameBuffer设备，还可以获得当前内核所支持的加速显示卡的类型（通过固定信息得到），这种类型通常是和特定显示芯片相关的。

比如目前最新的内核（2.4.9）中，就包含有对S3、Matrox、nVidia、3Dfx 等等流行显示芯片的加速支持。

在获得了加速芯片类型之后，应用程序就可以将 PCI设备的内存I/O（memio）映射到进程的地址空间。

这些memio一般是用来控制显示卡的寄存器，通过对这些寄存器的操作，应用程序就可以控制特定显卡的加速功能。

PCI设备可以将自己的控制寄存器映射到物理内存空间，而后，对这些控制寄存器的访问，给变成了对物理内存的访问。

因此，这些寄存器又被称为"memio"。

一旦被映射到物理内存，Linux的普通进程就可以通过 mmap 将这些内存 I/O 映射到进程地址空间，这样就可以直接访问这些寄存器了。

当然，因为不同的显示芯片具有不同的加速能力，对memio的使用和定义也各自不同，这时，就需要针对加速芯片的不同类型来编写实现不同的加速功能。

比如大多数芯片都提供了对矩形填充的硬件加速支持，但不同的芯片实现方式不同，这时，就需要针对不同的芯片类型编写不同的用来完成填充矩形的函数。

FrameBuffer 只是一个提供显示内存和显示芯片寄存器从物理内存映射到进程地址空间中的设备。

所以，对于应用程序而言，如果希望在FrameBuffer 之上进行图形编程，还需要自己动手完成其他许多工作。

*二、FrameBuffer在Linux中的实现和机制*Framebuffer对应的源文件在linux/drivers/video/目录下。

总的抽象设备文件为fbcon.c，在这个目录下还有与各种显卡驱动相关的源文件。

(一)、分析Framebuffer设备驱动需要特别提出的是在INTEL平台上，老式的VESA1.2卡，如CGA/EGA卡，是不能支持Framebuffer的，因为Framebuffer 要求显卡支持线性帧缓冲，即CPU可以访问显缓冲中的每一位，但是VESA1.2 卡只能允许CPU一次访问64K的地址空间。

FrameBuffer设备驱动基于如下两个文件：1) linux/include/linux/fb.h2) linux/drivers/video/fbmem.c 下面分析这两个文件。

1、fb.h几乎主要的结构都是在这个中文件定义的。

这些结构包括：1）fb_var_screeninfo这个结构描述了显示卡的特性：struct fb_var_screeninfo{__u32 xres; /* visible resolution */__u32 yres;__u32 xres_virtual; /* virtual resolution */__u32 yres_virtual;__u32 xoffset; /* offset from virtual to visible resolution */__u32 yoffset;__u32 bits_per_pixel; /* guess what */__u32 grayscale; /* != 0 Gray levels instead of colors */struct fb_bitfield red; /* bitfield in fb mem if true color, */struct fb_bitfield green; /* else only length is significant */struct fb_bitfield blue;struct fb_bitfield transp; /* transparency */__u32 nonstd; /* != 0 Non standard pixel format */__u32 activate; /* see FB_ACTIVATE_* */__u32 height; /* height of picture in mm */__u32 width; /* width of picture in mm */__u32 accel_flags; /* acceleration flags (hints) *//* Timing: All values in pixclocks, except pixclock (of course) */__u32 pixclock; /* pixel clock in ps (pico seconds) */__u32 left_margin; /* time from sync to picture */__u32 right_margin; /* time from picture to sync */__u32 upper_margin; /* time from sync to picture */__u32 lower_margin;__u32 hsync_len; /* length of horizontal sync */__u32 vsync_len; /* length of vertical sync */__u32 sync; /* see FB_SYNC_* */__u32 vmode; /* see FB_VMODE_* */__u32 reserved[6]; /* Reserved for future compatibility */};2) fb_fix_screeninfon这个结构在显卡被设定模式后创建，它描述显示卡的属性，并且系统运行时不能被修改；比如FrameBuffer内存的起始地址。

它依赖于被设定的模式，当一个模式被设定后，内存信息由显示卡硬件给出，内存的位置等信息就不可以修改。

struct fb_fix_screeninfo {char id[16]; /* identification string eg "TT Builtin" */unsigned long smem_start; /* Start of frame buffer mem *//* (physical address) */__u32 smem_len; /* Length of frame buffer mem */__u32 type; /* see FB_TYPE_* */__u32 type_aux; /* Interleave for interleaved Planes */__u32 visual; /* see FB_VISUAL_* */__u16 xpanstep; /* zero if no hardware panning */__u16 ypanstep; /* zero if no hardware panning */__u16 ywrapstep; /* zero if no hardware ywrap */__u32 line_length; /* length of a line in bytes */unsigned long mmio_start; /* Start of Memory Mapped I/O *//* (physical address) */__u32 mmio_len; /* Length of Memory Mapped I/O */__u32 accel; /* Type of acceleration available */__u16 reserved[3]; /* Reserved for future compatibility */};3) fb_cmap描述设备无关的颜色映射信息。

合集下载

glframebuffertexture2d用法

glframebuffertexture2d用法

glframebuffertexture2d用法【实用版】目录1.GLFRAMEBUFFERTEXTURE2D 概述2.GLFRAMEBUFFERTEXTURE2D 的参数3.GLFRAMEBUFFERTEXTURE2D 的用法示例4.GLFRAMEBUFFERTEXTURE2D 的错误处理正文【1.GLFRAMEBUFFERTEXTURE2D 概述】GLframebuffertexture2d 是 OpenGL 中的一个函数，用于将纹理图像绑定到帧缓冲区。

帧缓冲区是 OpenGL 中用于存储渲染到屏幕上的图像的缓冲区。

纹理图像则是 OpenGL 中用于存储二维图像的资源。

通过将纹理图像绑定到帧缓冲区，我们可以将纹理图像渲染到屏幕上。

【2.GLFRAMEBUFFERTEXTURE2D 的参数】GLframebuffertexture2d 函数的参数包括以下几个：- target：绑定纹理图像的帧缓冲区。

- texture：要绑定的纹理图像。

- level：纹理图像的哪个层级。

- border：纹理图像的边界模式。

【3.GLFRAMEBUFFERTEXTURE2D 的用法示例】以下是一个使用 GLFRAMEBUFFERTEXTURE2D 函数的示例：```c#include <GL/glut.h>int main(int argc, char** argv){// 初始化 OpenGLglutInit(&argc, argv);glutCreateWindow("GLFRAMEBUFFERTEXTURE2D Example");glutDisplayFunc(draw);glutMainLoop();return 0;}void draw(){// 设置清除颜色glClearColor(0.0f, 0.0f, 0.0f, 0.0f);glClear(GL_COLOR_BUFFER_BIT);// 绑定帧缓冲区glBindFramebuffer(GL_FRAMEBUFFER, 0);// 创建一个纹理图像glGenTextures(1, &texture);glBindTexture(GL_TEXTURE_2D, texture);glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, 512, 512, 0, GL_RGB, GL_UNSIGNED_BYTE, NULL);// 将纹理图像绑定到帧缓冲区glFramebufferTexture2D(GL_FRAMEBUFFER,GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, texture, 0);// 设置视图矩阵glMatrixMode(GL_PROJECTION);glLoadIdentity();glOrtho(0, 512, 512, 0, -1, 1);glMatrixMode(GL_MODELVIEW);// 绘制纹理图像glDrawArrays(GL_TRIANGLES, 0, 6);// 交换缓冲区glutSwapBuffers();}```【4.GLFRAMEBUFFERTEXTURE2D 的错误处理】在使用 GLFRAMEBUFFERTEXTURE2D 函数时，可能会遇到一些错误，例如纹理图像未创建、纹理图像未绑定等。

Android系统Surface机制的SurfaceFlinger服务对帧缓冲区(Frame Buffer)的管理分析

Android系统Surface机制的SurfaceFlinger服务对帧缓冲区(Frame Buffer)的管理分析

Android系统Surface机制的SurfaceFlinger服务对帧缓冲区（Frame Buffer）的管理分析在前文中，我们分析了SurfaceFlinger服务的启动过程。

SurfaceFlinger服务在启动的过程中，会对系统的硬件帧缓冲区进行初始化。

由于系统的硬件帧缓冲区一般只有一个，并且不是谁都可以随便访问的，因此，它就需要由一个服务来统一管理。

在Android系统中，这个服务便是SurfaceFlinger。

在本文中，我们就详细分析SurfaceFlinger服务是如何管理系统的硬件帧缓冲区的。

从前面一文可以知道，SurfaceFlinger服务通过一个GraphicPlane对象来描述系统的显示屏，即系统的硬件帧缓冲区。

GraphicPlane类内部聚合了一个DisplayHardware 对象，通过这个DisplayHardware对象就可以访问系统的硬件帧缓冲区。

DisplayHardware类内部又包含了一个FramebufferNativeWindow对象，这个FramebufferNativeWindow对象才是真正用来描述系统的硬件帧缓冲区的。

FramebufferNativeWindow类的作用类似于在前面一文中所介绍的Surface类，它是连接OpenGL库和Android的UI系统的一个桥梁，OpenGL 库就是通过这个桥梁来将Android系统的UI渲染到硬件帧缓冲区中去的。

GraphicPlane、DisplayHardware和FramebufferNativeWindow这三个类的关系如图1所示。

接下来，我们就分别介绍GraphicPlane、DisplayHardware和FramebufferNativeWindow这三个类的实现，以便可以理解SurfaceFlinger服务是如何通过它们来管理系统的硬件帧缓冲区的。

从前面一文可以知道，SurfaceFlinger服务在启动的过程中，会对系统的硬件帧缓冲区进行初始化，如下所示：[cpp] view plain copy 在CODE上查看代码片派生到我的代码片status_t SurfaceFlinger::readyToRun(){......// we only support one display currentlyint dpy = 0;{// initialize the main displayGraphicPlane& plane(graphicPlane(dpy));DisplayHardware* const hw = new DisplayHardware(this, dpy);plane.setDisplayHardware(hw);}......// initialize primary screen// (other display should be initialized in the same manner, but// asynchronously, as they could come and go. None of this is supported// yet).const GraphicPlane& plane(graphicPlane(dpy));const DisplayHardware& hw = plane.displayHardware();......hw.makeCurrent();......}这个函数定义在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp文件中。

framebuffer总结

framebuffer总结

Fb利用的是platform虚拟总线，按总线、设备、驱动模型
Platform有driver__init中调用platform_bus_init注册一个虚拟总线
arch_initcall的Rk29_ddr3中调用platform_add_devices（）将rk29_fb设备注册，添加到总线fs_initcall中调用platform_driver_register(&rk29fb_driver)注册驱动
五、从整体上再描述一下FrameBuffer设备驱动实例代码的结构：
1、在第①部分代码中主要做的事情有：
a.将LCD设备注册到系统平台设备中；
b.定义LCD平台设备结构体lcd_fb_driver。

2、在第②部分代码中主要做的事情有：
a.获取和设置LCD平台设备的各种资源；
b.分配fb_info结构体空间；
c.初始化fb_info结构体中的各参数；
d.初始化LCD控制器；
e.检查fb_info中可变参数；
f.申请帧缓冲设备的显示缓冲区空间；
g.注册fb_info。

3、在第③部分代码中主要做的事情有：
a.实现对fb_info相关参数进行检查的硬件接口函数；
b.实现对LCD显示模式进行设定的硬件接口函数；
c.实现对LCD显示开关(空白)的硬件接口函数等。

framebuffer-con0-alldata 类型 -回复

framebuffer-con0-alldata 类型 -回复

framebuffer-con0-alldata 类型-回复什么是framebuffercon0alldata？framebuffercon0alldata是一种数据类型，它与图形显示和渲染相关的技术和系统中起着重要的作用。

在计算机图形处理中，framebuffer是用于存储图像的内存区域，它被称为帧缓冲区。

而con0alldata代表了对这个帧缓冲区的所有数据的引用。

帧缓冲区是GPU中一个重要的内存区域，用于存储图像的像素数据。

这些像素数据包括颜色、深度、反射等信息。

framebuffercon0alldata类型可以理解为对这些数据的引用，使得我们可以有效地对图像进行处理、编辑和分析。

在计算机图形渲染中，帧缓冲区是一个重要的概念。

当我们渲染一个图像时，通常需要进行多个步骤，例如几何处理、光照模拟和纹理映射等。

这些步骤都需要通过framebuffercon0alldata类型来传递数据。

framebuffercon0alldata类型的引入使得图形渲染和显示的流程更加灵活和高效。

它可以帮助我们在不同的图形处理阶段传递数据，减少不必要的数据复制和内存开销。

此外，它还可以支持多线程和并行计算，提高渲染的效率。

使用framebuffercon0alldata类型可以使得图形处理和显示的系统更加模块化和可扩展。

我们可以将不同的处理步骤封装成独立的函数或模块，并使用framebuffercon0alldata类型来传递数据。

这种模块化的设计使得系统更容易维护和调试。

总结一下，framebuffercon0alldata类型在计算机图形处理和显示系统中起着重要的作用。

它可以帮助我们高效地传递图像数据，支持多线程和并行计算，并使系统更加模块化和可扩展。

在未来的发展中，framebuffercon0alldata类型有望继续发挥重要的作用，推动计算机图形处理技术的进一步发展和创新。