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下面的代码，因为这部分已经感觉像是应用的东西了，不过还是让我开了一下眼界。第一个任务就这样结束了