framebuffer的显示原理以及缺点分析

1、概述

在使用LCD的时候，存在这样两个问题：
1）、linux内存中，对内存管理严格，显存需要申请，不能想用就用。
2）、linux是工作在保护模式下的，每个应用程序都有自己的虚拟地址空间，这就导致应用程序不能直接访问LCD设备在内核中实际的物理缓冲区地址。
为了解决上述问题，我们引入framebuffer，帧缓冲。
注：
1）、帧缓冲：是一种机制，通过framebuffer机制，应用程序可以直接操作内核里面的显存。
2）、帧缓冲设备可以通过mmap()映射将屏幕缓冲区的物理地址映射到用户空间的的一块虚拟地址上。对用户空间以设备文件节点的形式暴露出来/dev/fbX(x=0-31,也就是他最大支持32个framebuffer.他们的主设备号都是29) 由此，引出3）：。用户通过读写这段虚拟地址，就可以访问屏幕缓冲区，实现在屏幕上绘图了。
frambuffercd相当于一个水池。每个lcd内都有一个sram,cpu内部有个LCD控制器，它会将framebuffer里面的数据拷贝到LCD的sram里面，拷贝到sram中的数据会显示在LCD上。同样，用户程序也可以直接从这个“水池“中读到数据。
由此，引出4）：
3）、LCD驱动，是platform驱动。当驱动和设备匹配以后，probe函数就会执行。他所执行的操作总是要就是：
向申请、初始并向内核注册Framebuffer(fb_info)。
在内核中，Framebuffer被抽象成事一个fb_info结构体。
换言之，LCD驱动的编写，其实就是：
a、向用户空间提供文件操作接口函数。
b、构建fb_info结构体，并向内核注册fb_info结构体的过程。驱动编写好以后，就会生成一个/dev/fbX的设备文件。
framebuffer设备驱动（字符设备驱动）的结构图：

4）、有人认为“操作LCD显示，实质上就是在操作framebuffer”，从表面上来看，确实是这样子。但是，仔细分析，会发现问题。实质上，framrbuffer就是linux内核驱动申请的一片物理空间。因此，从这可以看出，LCD驱动和framebuffer驱动没有必然的联系，LCD驱动只是驱动LCD正常的工作，eg:有信号传来，LCD驱动负责将信号转成LCD显示屏上的内容，至于是什么内容，怎么显示，LCD驱动并不关心。对于帧缓冲，只需要将显示的缓冲区与显示数据的RGB颜色值一一对应，RGB数据通过LCD控制器发送给LCD的sram，实现在屏幕上的显示。
framebuffer的显示原理：

2、framebuffer的缺点

1）、当只使用一个framebuffer的时候， 会存在这样一问题：就是framebuffer同时被应用程序写和驱动程序读（LCD控制器搬运）。如果应用程序写入的速度慢，将会导致画面显示的很慢或者闪烁。为了解决这个问题，可以使用两个或多个framebuffer。只有应用程序向framebuffer写入数据完成的时候，才让LCD控制器去搬运数据。在这个期间，应用程序向另一个framebuffer写入数据，这样循环往复，解决上述问题。
2）、在做界面的时候，存在的问题
假设两个界面切换，如果这两个界面的区别不大，若还是使用之前的方法—》逐一描绘，显然做了大量重复的操作。为了解决这个问题，我们将界面进行分层（eg:状态栏：第一层；背景，第二层；图标，第三层），一个层用一个framebuffer来描绘。最后借助硬件（HardWare ConPoser—>HWC）进行硬件合并，然后将合并后的图片显示。
在实际的应用中，我们如果要使用屏幕，都是通过UI库的。我们只需要告诉UI库，我们这个LCD对应的设备是dev/fbx，UI库就会使用dev/fbx创建他的一整套UI库，我们直接调用UI库提供的函数即可，eg：QT.通过QT的那一套，做界面，就可以了。