n32926的vpost 显示接口模块提供了两个层，一个是视频输出层，一个是OSD层。
我在官方vin_demo程序的基础上，调试实验了一下该功能，发现有几个问题：
1） 摄像头为YUV格式，在图像预览输出的时候，需要将Framebuffer（第一层）设置为YUV格式，此时OSD也需要设置为YUV，否则不能正常工作。不知道结论是否准确，大家有没有碰到该问题？ 非视频预览状态，FB一般是设置为RGB模式的，一般GUI均支持RGB格式，不支持YUV格式，如果OSD必须用YUV，就给UI的实现带来了很多了限制。
2）OSD和视频的Alpha混合貌似只能全局的，这样的话，局部的半透明怎么实现呢？
离线
不好意思各位，前面判断错误。。。在视频预览为yuv模式下，也可以使用rgb模式的osd
这样的话，osd实现就要方便很多了，可以统一使用rgb模式
离线
官方有linux 应用程序有一个osd的demo，里面默认就是RGB的，可以直接看效果，里面的功能比较完整，我只是测试下自己的想法
离线
我是这样理解的：
1） OSD层其实也是做成了FB驱动，在内存分配的时候是紧靠着第一层（fb0），只是没有像多数厂商做法，直接弄成fb1、fb2。
2）如果系统中没有视频相关，我觉得放哪一层都无所谓；如果有视频，因为视频层一般都是硬件辅助实现，如果和ui放到同一层用软件实现，势必加重cpu负担。
离线
nuvoton的fb驱动我分析过，在视频采集端口开启预览的时候，直接将该视频地址指向fb的地址，这样就省去了从采集端口到输出端口的内存copy步骤，提高了实时性，降低了cpu负担。
离线
默认驱动应该是不支持你说的这个情况。视频dma可以设置行跳跃寄存器（Output Frame Pixel Stride Width 【VSTRIDE】），结合起始地址，可以控制视频在FB中的位置，前提是视频的尺寸要小于FB的尺寸。
离线
您好，我也是刚刚接触这款芯片，看了官方SDK给的h264e历程，也分析了很久的驱动，水品有限，并没有发现您说的“在视频采集端口开启预览的时候，直接将该视频地址指向fb的地址”，可以分享一下您分析的过程吗，谢谢！！！
nuvoton的fb驱动我分析过，在视频采集端口开启预览的时候，直接将该视频地址指向fb的地址，这样就省去了从采集端口到输出端口的内存copy步骤，提高了实时性，降低了cpu负担。
离线
视频采集驱动源码路径linux-2.6.35.4\drivers\media\video\w55fa92_dev1
涉及到几个关键文件：
videoin.c 驱动入口文件
sensor_nt99141.c sensor控制
DevVin1.c 采集端口1的控制
vin_ioctl.c V4L驱动的ioctl
Sensor_ctl.c 辅助功能，控制sensor电源
nuvoton提供了一个vin_demo程序，里面有StartPreview() StopPreview() 函数，顺着这些函数调用的ioctl，找到驱动里面的对应函数，可以分析出每步的具体操作。
离线
按照您说的，重新查看了一下历程代码，在StartPreview()中ioctl(s_sVidData.i32VidFD, VIDIOCSPREVIEW, 1)这句中找到VIDIOCSPREVIEW这个命令，然后从内核中查找，在videoin.c文件中发现一个可以变量w55fa92_VIN_PAC_BUFFER，该变量在w55fa92_fb.c(LCD驱动文件)中被引用(extern unsigned int w55fa92_VIN_PAC_BUFFER),往下跟踪，最后找到outl(w55fa92_VIN_PAC_BUFFER, REG_LCM_FSADDR)，而REG_LCM_FSADDR正是LCD驱动显存的基地址，由此可以看到，内核将摄像头图像采集地址确实就是LCD的显存地址。
视频采集驱动源码路径linux-2.6.35.4\drivers\media\video\w55fa92_dev1
涉及到几个关键文件：
videoin.c 驱动入口文件
sensor_nt99141.c sensor控制
DevVin1.c 采集端口1的控制
vin_ioctl.c V4L驱动的ioctl
Sensor_ctl.c 辅助功能，控制sensor电源nuvoton提供了一个vin_demo程序，里面有StartPreview() StopPreview() 函数，顺着这些函数调用的ioctl，找到驱动里面的对应函数，可以分析出每步的具体操作。
离线
重新整理了一下FB的内核驱动，将一些重点部分都列下下面，希望对大家有点帮助
osd_cpu_mmap /*虚拟内存*/
osd_dma_mmap /*物理内存*/
//w55fa92_VIN_PAC_BUFFER为摄像头采集地址
outl(w55fa92_VIN_PAC_BUFFER, REG_LCM_FSADDR)
/*set frambuffer start phy addr*/
outl(video_dma_mmap, REG_LCM_FSADDR);
w55fa92_write()
if (g_osd_fristWrite)
osd_buf_addr = osd_cpu_mmap;
osd_buf_addr += osd_block.y0 * LCDWIDTH * PIXEL_BSIZE;
osd_buf_addr += osd_block.x0 * PIXEL_BSIZE;
g_osd_buf_addr = osd_buf_addr;
else
osd_buf_addr = g_osd_buf_addr;
g_osd_fristWrite = 0;
g_osd_buf_addr = osd_buf_addr;
w55fa92fb_probe()
ret = w55fa92fb_map_video_memory(info);
/* video_buf_mmap is the LCD physical starting address, cpu is the virtual */
video_cpu_mmap=(unsigned long)fbi->map_cpu;
video_dma_mmap=(unsigned long)fbi->map_dma;
/*video_buf_mmap=(unsigned long)fbi->map_size;*/
osd_cpu_mmap=(unsigned long)video_cpu_mmap + fbi->map_size;
osd_dma_mmap=(unsigned long)video_dma_mmap + fbi->map_size;
osd_size = fbi->map_size;
w55fa92fb_set_lcdaddr(info);
/*set frambuffer start phy addr*/
outl(video_dma_mmap, REG_LCM_FSADDR);
outl(osd_dma_mmap, REG_LCM_OSD_ADDR);
w55fa92fb_ioctl
case OSD_SEND_CMD:
w55fa92fb_ioctl_additional
case OSD_SEND_CMD:
w55fa92_osd_function(&osd_buffer);
case OSD_FillBlock:
osd_block = *osd_ptr;
g_osd_fristWrite = 1;
按照您说的，重新查看了一下历程代码，在StartPreview()中ioctl(s_sVidData.i32VidFD, VIDIOCSPREVIEW, 1)这句中找到VIDIOCSPREVIEW这个命令，然后从内核中查找，在videoin.c文件中发现一个可以变量w55fa92_VIN_PAC_BUFFER，该变量在w55fa92_fb.c(LCD驱动文件)中被引用(extern unsigned int w55fa92_VIN_PAC_BUFFER),往下跟踪，最后找到outl(w55fa92_VIN_PAC_BUFFER, REG_LCM_FSADDR)，而REG_LCM_FSADDR正是LCD驱动显存的基地址，由此可以看到，内核将摄像头图像采集地址确实就是LCD的显存地址。
tom 说：视频采集驱动源码路径linux-2.6.35.4\drivers\media\video\w55fa92_dev1
涉及到几个关键文件：
videoin.c 驱动入口文件
sensor_nt99141.c sensor控制
DevVin1.c 采集端口1的控制
vin_ioctl.c V4L驱动的ioctl
Sensor_ctl.c 辅助功能，控制sensor电源nuvoton提供了一个vin_demo程序，里面有StartPreview() StopPreview() 函数，顺着这些函数调用的ioctl，找到驱动里面的对应函数，可以分析出每步的具体操作。
离线
自从上家离职后，很久没用过926了，还是感谢楼上朋友们分享知识!
离线