DRM全解析 —— CRTC详解（1）

最新推荐文章于 2025-02-01 16:40:28 发布
最新推荐文章于 2025-02-01 16:40:28 发布
阅读量2.3k 收藏 4
点赞数
CC 4.0 BY-SA版权
分类专栏： DRM 文章标签： DRM
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/phmatthaus/article/details/133642650
本文介绍了Linux内核中的DRM（Direct Rendering Manager）框架中的CRTC（CRT Controller）概念，包括其作为显示控制器的功能，如控制显示时序、分辨率和刷新率，并连接framebuffer和encoder。还探讨了drm_crtc核心结构体，列出其主要成员如dev、port、head和name。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

本文参考以下博文：

Linux内核4.14版本——drm框架分析(4)——crtc分析

特此致谢！

1. 简介

CRTC实际上可以拆分为CRT+C。CRT的中文意思是阴极摄像管，就是当初老电视上普遍使用的显像管（老电视之所以都很厚，就是因为它的缘故）。而后边那个C，代表Controller即控制器（一说是Context即上下文）。

CRTC主要用于显示控制，如对于显示时序、分辨率、刷新率等的控制，还要承担将framebuffer（帧缓冲）内容送显、更新framebuffer等任务。

CRTC对内连接framebuffer地址，对外连接encoder。扫描framebuffer上的内容，叠加上 planes的内容，最后传给encoder。

CRTC在系统中的位置和作用如下所示：

了解本专栏 订阅专栏 解锁全文 超级会员免费看
DRM全解析 —— CRTC详解（4）
phmatthaus的专栏
10-08 747
DRM全解析 —— CRTC详解（4）
图显系统DRM CRTC完全解析
多年芯片设计领域从业经验，负责芯片bringup以及kernel驱动开发。
09-12 8312
目录 CRTC 工作原理和意义 CRTC 模块的初始化和功能 0. 引言 DRM 下的 CRTC 代表 RGB 数据管道，从&drm_plane 接收像素数据并将其混合到一起，传输给下级显示设备&drm_encoder。由&drm_display_mode 控制时序。 KMS 通过 drm_crtc_init_with_planes()注册&struct drm_crtc 并初始化 CRTC 模块。 通过 drm_crtc_helper_add()注册 CRTC 提
DRM全解析 —— CRTC详解（2）
phmatthaus的专栏
10-07 729
DRM全解析 —— CRTC详解（2）
Linux内核4.14版本——drm框架分析(4)——crtc分析
yangguoyu8023的博客
03-04 3910
drm框架分析 crtc分析
Rockchip RK3399 - DRM crtc基础知识
Graceful_scenery的博客
10-20 1377
一、LCD硬件原理 1.1 CRT介绍 CRT是阴极射线管(Cathode Ray Tube)的缩写，它是一种使用电子束在荧光屏上创建图像的显示设备。CRT显示器在过去很长一段时间内是主流的显示技术，现已被液晶显示屏或其他新兴技术所替代。 在CRT显示器中，扫描电子束从左到右、从上到下移动，照亮屏幕上的荧光点，从而创建图像。电子束每秒多次扫描整个屏幕，产生闪烁效果，需要与正在显示的内容同步。 随...
DRM全解析 —— CRTC详解（3）
phmatthaus的专栏
10-07 808
DRM全解析 —— CRTC详解（3）
DRM框架（vkms）分析（5）----crtc初始化
M120674的专栏
02-20 4946
drm_crtc结构体类型如下： /** * struct drm_crtc - central CRTC control structure * * Each CRTC may have one or more connectors associated with it. This structure * allows the CRTC to be controlled. */ struct drm_crtc { /*挂载到&drm_mode_config.crtc_list*/
DRM全解析 —— encoder详解（3）
phmatthaus的专栏
10-08 251
DRM全解析 —— encoder详解（3）
drm中如何找crtc，vblank page flip实现
sunxiaopengsun的专栏
07-27 2869
/* retrieve resources */ drmModeRes *res; res = drmModeGetResources(fd); 通过drmModeGetResources能获取到有限个connector和crtc。而某个connector是否能与某个crtc一起协同工作，需要encoder的支持。每个connector都有有限个可供使用的encoder列表，而encoder需要与crtc适配上才能工作。 每个连接器都有一个可供使用的编码器的有限列表，可以通过conn->c
Linux 中基于 DRM 的图形显示系统概述
龙图腾的博客
03-16 2815
Linux系统中图形显示方案1 FBDEV Framebuffer device 社区参与度不高，基本转移到了DRM。 DRM/KMS Direct Rendering Manager / KernelMode Setting 主流的图形显示方法，社区参与度高，支持图形系统精细化操作，基本形成了一套图显系统开发的生态标准。 V4L2 Video For Linux 2 主要用于视频捕获的应用场景，并且需要特定输出设备，对复杂图显控制器的支持不佳 DRM系统组成2kernel层
DRM驱动（八）之crtc_state生命周期
fengchaochao123的博客
03-17 2280
本文介绍了drm中各个组件state的创建，使用和销毁的生命周期。算是对之前内容的补充，把一些细节放大来阐述。
crtc 原理
qq_38350702的博客
12-25 662
配置正确的显示设置，显示器时序和显示器分辨率。将framebuffer的内容扫描输出到一个或多个显示器。更新 frame buffer，通过 struct drm_crtc_funcs 和 struct drm_crtc_helper_funcs 两个结构体来实现。
图显系统DRM PLANE完全解析
多年芯片设计领域从业经验，负责芯片bringup以及kernel驱动开发。
09-12 4589
目录 PLANE的工作原理和意义 PLANE的初始化和功能 0. 引言 DRM PLANE 从 drm_framebuffer 接收数据，构造送显图像的雏形，完成图像的剪裁和缩放后发送到&drm_crtc。 除此之外，还通过 drm_plane_state 来提供图像旋转功能。 KMS 驱动通过调用 drm_universal_plane_init()初始化 DRM PLANE。每个 CRTC 需要定义一个 primary plane 以及可选的 overlay plane、cursor p.
Linux DRM的基本框架和原理
tombaby_come的博客
07-26 3181
Linux内核有一个名为fbdev(一个Linux子系统，用于在计算机显示器上显示图形，通常在系统控制台上)的API，用于管理图形适配器（）的帧缓冲区，但它无法处理现代基于GPU的3D加速视频硬件的需求。如下图所示：这些设备通常需要在自己的内存中设置和管理命令队列（command queue），以将命令分派到GPU，并且还需要管理该内存中的缓冲区和可用空间。最初，用户空间程序（例如X Server）直接管理这些资源，但它们通常表现得好像它们是唯一可以访问这些资源的程序。
Linux DRM详解：图形显示的核心组件与它们的相互作用
qq_30883899的博客
11-07 665
负责生成显示信号并控制显示内容的输出。管理显示模式（如分辨率和刷新率）和时序信号。CRTC、framebuffer、plane、encoder和connector之间的关系和运作方式共同构成了Linux图形显示系统的核心架构。它们的协作使得系统能够高效地管理图形内容的显示，实现多层次和高质量的图形输出。理解这些组件的功能和相互关系，有助于深入掌握Linux图形系统的工作原理。
Linux图形子系统之setCRTC流程
fs3296的博客
03-29 2871
Linux图形子系统之setCRTC流程引言1 drm_mode_setcrtc2 drm_atomic_helper_set_config3 drm_atomic_helper_commit 引言 drm通过DRM_IOCTL_MODE_SETCRTC实现最原始的模式设置和送显操作。 1 drm_mode_setcrtc drm_mode_setcrtc是DRM_IOCTL_MODE_SETCRTC的处理函数。其源码如下： int drm_mode_setcrtc(struct drm_device *d
DRM系列二：DRM总体介绍
sdsc1314的博客
02-01 1182
DRM，全称Direct Rending Manger。是目前Linux主流的图形显示框架。相比较传统的Framebuffer（FB原生不支持多层合成，不支持VSYNC，不支持DMA-BUF，不支持异步更新，不支持fence机制等等），而这些功能DRM原生都支持，因此DRM更能适应当今硬件。并且DRM可以支持GPU、3D渲染显示等，统一管理GPU、Display驱动，使得软件架构更统一、方便开发和维护。
DRM设备信息
qq_31351705的博客
08-20 1556
在DRM（Direct Rendering Manager）中，resources、connector、mode、encoder 和 CRTC 是显示管线的重要组成部分。它们之间有着紧密的关系，形成了从图像生成到输出的完整路径
drm 学习笔记-2：DRM介绍
一个走路缓慢的人
08-12 6215
linux kernel最早是使用fbdev API来管理图形显示的framebuffer，但是不能满足基于GPU的现代3D硬件加速技术。这些设备通常需要在自己的内存中创建和管理command queue,以便将command分发给GPU进行渲染，并且还需要对内存进行管理如buffer和可用空间。最初，用户程序(如X Server)直接管理这些资源，但通常只有一个程序访问，当2个及以上程序同时访问相同硬件时，并以不同的方式设置每个硬件资源时大多数情况下会发生异常(图1)。图1。...............
drm_atomic_crtc_set_property这种提供给user的api函数，要怎么去追调用
最新发布
04-09
<think>好的，我现在需要帮助用户了解如何追踪`drm_atomic_crtc_set_property`这个用户API函数的调用流程。首先，我得确认自己对这个问题有足够的理解。用户提到这是一个提供给用户的API函数，所以应该属于DRM（Direct Rendering Manager）子系统的一部分，用于设置CRTC（阴极射线管控制器，在现代GPU中通常指显示控制器）的原子属性。 首先，我应该回忆一下DRM框架的基本结构。DRM在内核中负责处理图形渲染和显示输出，支持原子更新，允许用户空间程序通过ioctl调用来修改显示相关的属性，比如分辨率、色彩模式等。原子更新意味着所有的更改在一次操作中提交，避免中间状态导致的闪烁或不一致。 接下来，`drm_atomic_crtc_set_property`这个函数的作用可能是在原子提交过程中设置CRTC的属性。用户想知道如何追踪这个函数的调用流程，也就是从用户空间发起调用，经过内核的各个层次，直到这个函数被执行的过程。 为了追踪这个调用流程，我需要考虑以下几个方面： 1. **用户空间的API**：用户程序如何调用这个函数。通常DRM的用户空间接口是通过libdrm库提供的，而libdrm会通过ioctl系统调用与内核交互。因此，可能需要检查libdrm中相关的函数，比如`drmModeObjectSetProperty`。 2. **内核中的ioctl处理**：DRM驱动会注册一系列的ioctl处理函数，对应的命令可能是`DRM_IOCTL_MODE_ATOMIC`。当用户空间发起ioctl调用时，内核的DRM子系统会解析请求，并调用相应的处理函数。 3. **原子提交流程**：在原子模式下，用户空间会准备一个原子请求（drm_mode_atomic），其中包含多个属性的更改。内核会遍历这些属性，并针对每个对象（如CRTC、Plane、Connector）调用对应的set_property函数，这里就是`drm_atomic_crtc_set_property`。 4. **属性定义和操作**：每个CRTC属性在驱动中应该有对应的定义，包括属性ID、类型以及如何设置的回调函数。`drm_atomic_crtc_set_property`可能需要根据属性ID来调用不同的处理逻辑，或者将值传递给底层的硬件驱动。 现在，我需要将这些步骤具体化，并给出用户可以用来追踪调用的方法。可能需要使用调试工具，如ftrace、printk，或者动态调试（dynamic_debug）来在内核代码中添加日志，观察函数调用的路径。另外，查看内核源码中相关函数的调用关系也是必要的。 可能的步骤包括： - **查找用户空间调用路径**：确定用户程序如何通过libdrm发起设置属性的请求，比如使用`drmModeAtomicAddProperty`函数，然后提交原子请求。 - **分析内核ioctl处理**：在内核中，`drm_mode_atomic_ioctl`函数处理用户空间的原子提交请求。该函数会解析用户传递的drm_mode_atomic结构，逐个处理每个属性更新。 - **跟踪属性处理流程**：在原子提交过程中，对于每个CRTC的属性，内核会调用`drm_atomic_crtc_set_property`函数。这个函数可能进一步调用驱动特定的回调函数，比如`atomic_set_property`。 - **使用调试工具**：在关键函数中添加printk语句，或者启用DRM的调试输出（如启用动态调试开关`CONFIG_DRM_DEBUG_SELFTEST`），或者使用ftrace来跟踪函数调用图。 另外，需要考虑到不同内核版本之间的差异，函数名或流程可能有所变化。因此，用户需要根据自己使用的内核版本来调整追踪的方法。 可能遇到的问题包括： - 如何确定用户空间的调用对应到内核的哪个ioctl？ 这需要了解libdrm和内核之间的接口定义，通常libdrm的`xf86drmMode.h`中定义了相关的函数和结构体，而内核的`drm/drm_mode.h`定义了对应的ioctl命令和数据结构。 - 如何确认`drm_atomic_crtc_set_property`是否被正确调用？ 在函数内部添加调试输出，或者使用kprobes来动态跟踪函数的执行。 - 如果驱动没有正确实现该函数，或者属性未正确注册，应该如何排查？ 需要检查驱动代码中CRTC的初始化部分，确认属性是否通过`drm_object_attach_property`或类似函数注册，并且确认`atomic_set_property`回调是否被正确设置。 总结来说，追踪`drm_atomic_crtc_set_property`的调用流程需要结合用户空间的库函数、内核的ioctl处理、原子提交逻辑以及驱动中的具体实现。通过代码分析、调试工具和日志输出，可以逐步理清整个调用链。</think>要追踪`drm_atomic_crtc_set_property`函数的调用流程，可以按照以下步骤逐步分析： --- ### **1. 用户空间调用路径** 用户程序通过 **libdrm** 提供的接口发起属性修改请求： - **关键函数**：`drmModeAtomicAddProperty`（添加属性到原子请求）和`drmModeAtomicCommit`（提交请求）。 - **触发流程**： ```c drmModeAtomicAddProperty(atomic_req, crtc_id, property_id, value); drmModeAtomicCommit(fd, atomic_req, flags, NULL); ``` 提交后会触发`DRM_IOCTL_MODE_ATOMIC`的ioctl调用。 --- ### **2. 内核ioctl处理** 内核中处理原子提交的入口是`drm_mode_atomic_ioctl`函数： - **代码路径**：`drivers/gpu/drm/drm_atomic_uapi.c` - **关键操作**： - 解析用户传递的`drm_mode_atomic`结构。 - 遍历每个属性对象（CRTC、Plane、Connector等），调用对应的`set_property`函数。 - 对于CRTC属性，最终调用`drm_atomic_crtc_set_property`。 --- ### **3. 属性设置流程** 在`drm_atomic_crtc_set_property`中： - **代码路径**：`drivers/gpu/drm/drm_atomic.c` - **关键逻辑**： - 根据`property_id`匹配CRTC的属性列表。 - 将用户空间传递的`value`写入CRTC的原子状态（`drm_crtc_state`）。 - 可能触发驱动实现的回调（如`.atomic_set_property`）。 --- ### **4. 调试与追踪方法** #### **(1) 内核日志（printk）** 在关键函数中添加调试输出： ```c // 在drm_atomic_crtc_set_property中添加printk int drm_atomic_crtc_set_property(struct drm_crtc *crtc, struct drm_crtc_state *state, struct drm_property *property, uint64_t val) { printk(KERN_DEBUG "Setting CRTC%d property %s to %llu\n", crtc->base.id, property->name, val); // ...原有逻辑... } ``` 重新编译内核并查看`dmesg`输出。 #### **(2) 动态调试（Dynamic Debug）** 启用DRM子系统的动态调试： ```bash echo 'file drm_atomic* +p' > /sys/kernel/debug/dynamic_debug/control ``` 这会打印`drm_atomic`相关函数的调用信息。 #### **(3) Ftrace函数追踪** 使用ftrace追踪调用链： ```bash # 启用函数追踪 echo function > /sys/kernel/debug/tracing/current_tracer # 过滤DRM相关函数 echo "drm_atomic_*" > /sys/kernel/debug/tracing/set_ftrace_filter # 开始追踪 echo 1 > /sys/kernel/debug/tracing/tracing_on # 执行用户程序触发调用 cat /sys/kernel/debug/tracing/trace ``` #### **(4) 代码分析工具** 使用`cscope`或`ctags`在Linux内核源码中查找调用关系： ```bash # 在源码根目录生成索引 make cscope # 搜索drm_atomic_crtc_set_property的调用者 cscope -d -L3 drm_atomic_crtc_set_property ``` --- ### **5. 驱动实现示例** 检查驱动中CRTC属性的注册和回调： ```c // 驱动初始化时注册CRTC属性 static const struct drm_prop_enum_list prop_list[] = { {DRM_MODE_PROP_CRTC_MODE_ID, "MODE_ID"}, // ...其他属性... }; void my_crtc_init(struct drm_device *dev, struct drm_crtc *crtc) { // 创建属性 struct drm_property *prop = drm_property_create_range(dev, 0, "my_prop", 0, 100); // 将属性附加到CRTC drm_object_attach_property(&crtc->base, prop, 0); } // 实现atomic_set_property回调 static int my_crtc_atomic_set_property(struct drm_crtc *crtc, struct drm_crtc_state *state, struct drm_property *property, uint64_t val) { if (property == my_prop) { state->custom_value = val; // 保存到状态 return 0; } return -EINVAL; } ``` --- ### **常见问题排查** - **属性未生效**：检查驱动是否注册了对应属性，且`drm_atomic_crtc_set_property`是否正确处理了`property_id`。 - **内核崩溃**：确认传递的`value`范围合法，驱动回调未访问无效内存。 - **无调试输出**：检查内核配置是否启用`CONFIG_DRM_DEBUG`或动态调试未正确启用。 通过以上步骤，可以系统性地追踪`drm_atomic_crtc_set_property`的调用流程，定位问题根源。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

蓝天居士

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值