Android 画面显示流程一

本文介绍了Android系统的画面显示流程,重点讲解了从App通过SurfaceFlinger到Kernel的帧数据流。内容涉及DRM(Direct Rendering Manager)系统,包括KMS、DRI和GEM组件,以及用户空间帧数据如何经过SurfaceFlinger、HWC Service,最终通过kernel的drmModeAtomicCommit提交到硬件显示。
摘要由CSDN通过智能技术生成

DRM,英文全称 Direct Rendering Manager, 即 直接渲染管理器。
DRM是linux内核的一个子系统,提供一组API,用户空间程序,可以通过它,发送画面数据到GPU或者专用图形处理硬件,也可以使用它执行诸如配置分辨率,刷新率之类的设置操作。原本是设计提供PC设备支持复杂的图形设。
在DRM之前Linux内核已经有一个叫FBDEV的API,用管理图形适配器的帧缓存区,但不能用于满足基于3D加速的现代基于GPU的视频硬件的需求。

4.基本组件

DRM主要由如下部分组成:
KMS(Kernel Mode Setting): 主要是配置信息管理,如改变分辨率,刷新率,位深等。
DRI(Direct Rendering Infrastructure): 可以通过它直接访问一些硬件接口
GEM(Graphics Execution Manager): 主要负责内存管理,CPU, GPU对内存的访问控制由它来完成。
DRM Driver in kernel side: 访问硬件
在这里插入图片描述
其中KMS由frame buffer, CRTC, Encoder, Connector等组件组成
CRTC:CRT controller,目前主要用于显示控制,如显示时序,分辨率,刷新率等控制,还要承担将framebuffer内容送到display,更新framebuffer等。
Encoder
负责将数据转换成合适的格式,送给connector,比如HDMI需要TMDS信息, encoder就将数据转成HDMI需要的TMDS格式。
Connector
它是具体某种显示接口的代表,如 hdmi, mipi等。用于传输信号给外部硬件显示设备,探测外部显示设备接入。
Planes
一个Plane代表一个image layer, 最终的image由一个或者多个Planes组成
在Android系统上DRM就是通过KMS一面接收userspace交付的应用画面,一面通过其connector来向屏幕提交应用所绘制的画面。

3.2. Userspace的帧数据流

在Android系统上应用要绘制一个画面,首先要向SurfaceFlinger申请一个画布,这个画布所使用的buffer是SurfaceFlinger通过allocator service(vendor.qti.hardware.display.allocator-service)来分配出来的,allocator service是通过ION从kernel开辟出来的一块共享内存,这里申请的都是每个图层所拥有独立buffer, 这个buffer会共享到HWC Service里,由SurfaceFlinger来作为中枢控制这块buffer的所有权,其所有权会随状态不同在App, SurfaceFlinger, HWC Service间来回流转。在这里插入图片描述
而HWC Service正是那个使用libbrm和kernel打交道的人,他负责把SurfaceFlinger交来的图层做合成,将合成后的画面提交DRM去显示。

4.1. App到SurfaceFlinger

应该首先通过Surface的接口向SurfaceFlinger申请一块buffer,需要留意的是Surface刚创建时是不会有buffer被alloc出来的,只用应用第一次要绘制画面时dequeueBuffer会让SurfaceFlinger去alloc Buffer,在应用侧会通过importBuffer把这块内存映射到应用的进程空间来,这个过程可以在systrace上观察到。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值