http://blog.csdn.net/gaomaolin_88_163/article/details/6530914
问题:手机上的屏是好的,但是通过androidscreencast抓屏到PC机上却是花屏,
工具不行。
usb这条通路肯定是好的,我拿过来down了内核进去发现还真是花的,好像是像素错位了。当时我是一点思路都没有。这太奇怪了,手机上的屏是好的,居然抓出来的屏是花的,这跟驱动有关系吗?头的头儿说:framebuffer里面的数据不对,好像是32字节对其的问题。行我什么都不用想看看吧。我的想法是,既然手机本身的屏没有问题,那说明LCD驱动的写的这一路没有问题,
但抓屏这一路,应该是去读取framebuffer里面的数据,说明是读的这一路的问题,我把fbmem.c中的fb_fops结构体的的.read函数设为空,抓出来的屏就没有显示,说明它是通过读取这个数据去显示的。但我分析了一下读的这个函数根本没有任何的问题,因为这是LCD驱动比较靠上层的函数,所有的LCD驱动,它基本都是一样的。那接着就瞎改LCD参数吧,无意之中我把屏信息的xres从原来的240改成了320就能正常显示了,最后我又改成256也能正常显示,说明这个数必须是32的整数倍就好用了。当然我不能改这个xres来解决问题,这样的话那手机上的屏肯定就不能显示正确了。得根据这个去找原理,最后在程序中某处发现像一行的像素个数必须是32的整数倍,至于为什么是32的整数倍我现在还搞懂,这得再仔细看芯片手册看能不能找到答案,如果行像素个数不是32的整数倍的话,在计算分配的缓冲区长度的时候,就是会将行像素个数凑成32的整数倍,如果是240的话那就用256来算。一个像素用16bits(2bytes),那一行就多出来(256-240)*2=32个bytes.如果androidscreencast在抓屏时多抓了32个字节,而显示一行又只显240个像素,那么这剩下的32bytes==16个像素就移到下一行,这样整个图像就错位了,这只是我的分析。为了验证我的想法,我在fbmem.c的read函数中如果是读到240*2个字节的时候我就直接跳过接下的的32个字节。改了之后还是没有效果。这时我问了一个做这个驱动的同事,他说这个bug他已经解决了,给了我一个framebuffer_service.c说把system目录下面的.http://www.cnblogs.com/adb/framebuffer_service.c替换就好了,我实验了一下还真是好了,分析了一些他的改动和原版,大概意思和我分析的原因差不多,就是多出来的那32个字节的处理。不过这里的程序已经算是应用程序了,真是令我郁闷,我以前看的都是kernel下面的代码,而从来没有去分析过system下面的代码,因为这部分已经感觉像是应用的东西了,不过还是让我开了一下眼界。第一个任务就这样结束了