视频硬件负责为计算机系统生成可视化的输出
嵌入式SOC通常有一个片上LCD控制器，其输出的是TTL信号，他把18位的平板视频数据分组，三原色RGB每色6bit。
许多手持设备和电话使用QVGA类型的内部LCD面板，他们直接接收LCD控制器输出的TTL平板视频数据
Linux视频子系统 frame buffer
由于视频适配器可能基于不同的硬件体系架构，较高内核层和应用程序的实现可能会因视频卡不同而不同，这会造成差劲的可移植性和龙宇的代码。
frame buffer的引入解决了这个问题，他进行了一般化的抽象并规定变成接口，从而开发人员可以和平台无关的方式编写应用层和较高内核层的程序
视频控制器在每行结束时发送一个水平同步脉冲(HSYNC)
在每帧结束时发送一个垂直同步脉冲(VSYNC)
HSYNC和VSYNC是需要一定的持续时间的，他根据不同的LCD而不同
帧缓冲API
帧缓冲核心层向用户空间输出设备借点，方便应用程序能访问每个支持的视频设备
/dev/fbN是和帧缓冲设备N关联的节点，使用帧缓冲API主要要关心的数据结构定义在内核的include/linux/fb.h，而用户测的定义
帧缓冲相关结构
fb_var_screeninfo : 视频卡的可变属性，被包含在fb_info
fb_fix_screeninfo : 视频硬件的固定属性，被包含在fb_info
fb_cmap : 颜色映射,他把用户定义的颜色分配信息传给底层视频硬件，可以用该结构定义RGB的配比来获得不同的颜色分配
fb_info : 帧缓冲核心结构体,他代表一个/dev/fbN,由framebuffer_alloc()分配
fb_ops : 帧缓冲设备的操作表
彩色模式
视频硬件支持的常见颜色模式包括伪彩色和真彩色。
对于前者，索引号被映射称RGB像素编码，选择可用色彩的一个子集并使用对应颜色的索引而不使用像素值，就可以降低对帧缓冲内存的需求
但你的硬件需要支持这种可变色彩集(调色板)的机制
真彩色模式(常用)和可变色彩集机制无关，但你页需要满足帧缓冲控制台驱动程序的需求，他只使用了16色
因此，你只能把这16个原始RGB值编码称能直接送入硬件的位，也就是建立伪调色板，这个伪调色板保存在fb_info里的pseudo_palette字段
上面关于调色板的原书说明可能有点晦涩，本人在这里再详细的注解一下
调色板的诞生是因为如果把每一像素的RGB都写到内存里，会导致显存过大而诞生的。
那么调色板是怎么解决这个问题的？
就拿伪彩色LCD而言，他并不需要把RGB值写到内存，而是他事先弄好了一张表，这张表上写了各种颜色。
我们只需要把这张表的颜色对应的索引写到显存里,LCD控制器就会自动搜索表,然后取出像素值从而实现节省显存
而真彩色LCD，实际上他并不支持调色板，但LCD控制器他同样需要一个调色板(可能是为了兼容)
那么我们就需要“冒充”出来一个假的调色板
调色板一般被这么设置，下面的代码应该是fb_setcolreg里的代码
info->pseudo_palette[color_index] =
(red << info->var.red.offset) |
(green << info->var.green.offset) |
(blue << info->blue.offset) |
(transp << info->var.transp.offset);
LCD控制器每像素用16位(16bbp，也有24bbp的)描述使用RGB565格式(就是上面的offset)
因此fb_check_var()方法确保红绿蓝值分别位于位偏移11、5、0处
阅读(1365) | 评论(0) | 转发(0) |
