蜗窝科技

写的很好，才发现有这么好的一个地方，谢谢！ 希望能快点学习，以后我也能在这里写一篇文章。 :)

@passerby：对比理解了下代码，确实是高通的东西。高通为了增加对HMP的支持，对进程调度进行了很大的修改。所以代码变得不同了，增加了它的rq负载计算的机制。

@风痕：上面我和passerby的讨论，可能你理解错了。我没有这样的表述。

@wowo：你说得有问题吧，高等级可以使用低等级的寄存器，但是低等级不能使用高等级的寄存器。可以看看DEN0024A_v8_architecture_PG.pdf的表4.5

@郭健：其实我的目的就是，去不了现场，在远方看看下蛋的鸡长啥样，哈哈哈

@wowo：谢谢wowo，讲得很清楚~ 准备使用硬件的回写功能来实现，对我这样的新手是个挑战。

@schedule：对reader侧进行加锁操作（rcu_read_lock和rcu_read_unlock）其实主要是为了判断CPU是否经历一次Quiescent state，和数据保护无关

想到一个问题， 读取数据的时候为什么要加锁？ 读取的任何数据都是某个变量在某个时间点上正确的值，加锁是不是没有必要了

DRI所在的应用场景，远比Framebufffer复杂，因为硬件可以做很多事情，我们举一个支持双显的例子（这在现今的消费类系统是很常见的）： Plane 0--------------\ | Plane 1----------\ | | | V V Plane 2---->CRTC0------>Encoder0---->LCD (Scanout buffer 0) Plane 3----------\ | V Plane 4---->CRTC1------>Encoder1---->HDMI (Scanout buffer 1) 问题的关键点是： 1）Application可以同时送给DRI 7个framebuffer（Plane和Scanout buffer都是由framebuffer表示）。 2）而我们的硬件（CRTC），可以对这多个buffer自行处理（缩放、叠加、Alpha混合等）后，驱动显示控制器（Encoder）输出。 在这个过程中，我们不能简单的抓取任何一个framebuffer就可以完成屏幕录像。如果要做，只能在如下的2几个地方做： 1）我们的CRTC在将合成后的图像送到Encoder的时候，同时送一份给内存，其实就是硬件的回写功能。 2）由Application自行完成（这里的Application可能是合成器，如Wayland）。Application在将buffer送给CRTC的同时，调用软件API（OpenGL等））将这些buffer合成为一个，然后保存成文件。至于合成器是够提供这个功能，我也不是很清楚，要看你是使用什么样的GUI系统。 当然，如果系统没有Plane，每个CRTC也就只有一个Scanout buffer，就可以将DRI降级为简单的framebuffer设备。旧的方法（/dev/fbX）依旧是可行的。

@wowo：谢谢wowo。录屏的确是应用层的事情，但底层应该开放相应的entity给应用录屏，比如说 FrameBuffer显示框架可以通过访问/dev/fb0来录屏，Android应该也可以访问/dev/ graphics/fb0来录屏（没做过Android，此处仅是猜测）。DRI开放给应用程序的entity有/dev/dri/card0和/dev/dri/controlD64，而据我所知都不能用来录屏（也许可以只是我不知道）。所以想请教一下wowo，在DRI显示框架下，有什么好的办法或者建议来录屏？