1. 先弄清RK3588 Android12里到底有几个"阀门"在管屏幕
玩RK3588这板子的人，十个里有八个在第一次点屏的时候被"屏幕方向、分辨率、密度"这三件事绊过。原因不复杂：RK3588的显示子系统比早年的RK3288、RK3399复杂得多，VOP从一代升到了2.0/3.0，一颗芯片能同时挂HDMI0、HDMI1、DP、eDP、MIPI DSI0/DSI1、RGB/BT1120好几路输出，每一路都能独立配方向和分辨率。你在设备树里改一个数，未必能落到Android那一层；你在build.prop里改一个属性，未必能压过VOP的物理时序。所以真正动手之前，得先把"哪个参数在哪一层生效"这条线捋清楚，不然就是反复烧录、反复重启，一天下来屏还是歪的。
我自己第一次在RK3588上做竖屏一体机的时候就是这么过来的：ro.sf.hwrotation设了90，开机画面确实竖过来了，但开机logo还是横的，触摸也是反的，密度更是让设置界面挤成一团。后来才明白，这三件事其实是三个独立的问题，分别由设备树、厂商HWC、Android框架三层各自管一段。
1.1 从VOP到SurfaceFlinger：一条显示链路的分层
把RK3588 Android12的显示链路拆开看，从上到下大致是这么几层：
- 应用层：决定自己要画多大、要不要跟随系统旋转。
- WindowManager / ActivityManager：根据
user_rotation和屏幕的rotation设定窗口朝向。 - SurfaceFlinger：把所有图层合成到一个buffer里，它的输入尺寸由
DisplayDevice的mDisplayWidth/mHeight决定。 - HWC（硬件合成器）：Rockchip自己实现的HWC会读
ro.sf.hwrotation，在把图层交给VOP之前做一次硬件旋转。 - DRM/KMS驱动：把最终buffer的格式、尺寸、时序告诉VOP。
- VOP2/VOP3：真正的显示控制器，输出时序给MIPI DSI、HDMI这些接口。
- Panel/桥接芯片：最后落到物理屏。
关键点在于：ro.sf.hwrotation改的是HWC那一层，dts里的panel-timing改的是VOP那一层，而wm size改的只是SurfaceFlinger那一层。三者不在同一个位置，所以它们的表现也完全不同——设备树改错了会黑屏，HWC属性改错了会方向对但触摸错，wm size改错了会糊。
1.2 三个参数各自在哪儿生效，优先级怎么排
我习惯按"改动粒度"来排优先级，从底层往上：
| 参数 | 生效位置 | 典型文件/命令 | 影响范围 |
|---|---|---|---|
| 分辨率（物理） | VOP + Panel时序 | kernel-5.10/arch/arm64/boot/dts/rockchip/xxx.dtsi | 整块屏，全局 |
| 屏幕方向（物理） | HWC旋转 | ro.sf.hwrotation | 合成结果，全局 |
| 屏幕方向（逻辑） | WindowManager | settings put system user_rotation | 应用层可见的朝向 |
| 密度 | SurfaceFlinger | ro.sf.lcd_density/wm density | 所有按dp布局的界面 |
| 逻辑分辨率 | SurfaceFlinger | wm size | 缩放后的显示尺寸 |
这里有个很多人会搞混的地方：物理分辨率和逻辑分辨率是两码事。物理分辨率是VOP实际吐出去的像素数，由设备树决定，改不了运行时的；逻辑分辨率是Android认为屏幕有多大，wm size能改。你在一块1024x600的屏上执行wm size 1920x1080，屏幕不会变清晰，只会把1080p的画面缩放下来，反而更糊——因为多了两次采样。
注意：
wm size/wm density改的是persist.sys.display.size和persist.sys.display.density这类运行时属性，重启后需要重新设。要做成永久生效，还是得回到device.mk或system.prop里写ro.sf.lcd_density。
2. 屏幕方向：物理旋转和逻辑旋转不是一回事
方向这件事，最容易踩的坑就是"看起来对了"。你改完HWC旋转，开机动画竖过来了，以为搞定，结果一进桌面发现截图是横的、相机预览是反的、坐标轴全乱。这是因为Android里"方向"至少有三个概念在同时起作用，它们各自服务不同的目的。
2.1 ro.sf.hwrotation改的是合成阶段的旋转
ro.sf.hwrotation是Rockchip BSP里最常见的一个属性，值一般是0、90、180、270。它的作用点在HWC里：HWC收到SurfaceFlinger传来的图层后，如果检测到这个属性不为0，就会在合成时对输出做一次旋转，再交给VOP。
配置位置通常在：
device/rockchip/rk3588/xxx/system.prop 或者 device/rockchip/rk3588/xxx/BoardConfig.mk 里的 PRODUCT_PROPERTY_OVERRIDES写法很简单：
PRODUCT_PROPERTY_OVERRIDES += \ ro.sf.hwrotation=90但它的代价是：旋转后的画面是硬件转出来的，WindowManager并不知道。也就是说，SurfaceFlinger的DisplayDevice依然是按照未旋转的宽高来算的，只是物理输出被转了90度。这在竖屏一体机、广告机这类"整机固定朝向"的场景里够用，但如果你还要支持传感器自动旋转，就会打架。
我个人的经验是：如果整机是固定竖屏（比如电梯广告机、KTV点歌屏），用ro.sf.hwrotation=90最省事；如果要做平板形态、要支持自动旋转，那就别用HWC旋转，老老实实走user_rotation。
2.2 开机默认朝向与运行时锁定的区别
不想要HWC那套，就得分两步走：一步设默认朝向，一步锁住不让它乱转。
Android 12里运行时的方向由Settings.System.USER_ROTATION和ACCELEROMETER_ROTATION共同决定。手动指定：
# 关掉重力感应自动旋转 adb shell settings put system accelerometer_rotation 0 # 指定朝向：0=0度，1=90度，2=180度，3=270度 adb shell settings put system user_rotation 1也可以直接用wm命令：
adb shell wm set-user-rotation lock 1如果想让这个值在出厂时就定死，可以在框架层改默认值，或者更干净的做法是在产品配置里覆盖config_defaultRotation这类资源。Rockchip的BSP里一般会在frameworks/base/core/res/res/values/config.xml附近找到相关的默认值定义。
但对于大多数RK3588项目来说，更推荐的做法是在device.mk里写一个开机执行的脚本，在init.rc里用on boot阶段把settings put执行一遍。这样既能保证默认朝向，又不会把框架改得乱七八糟，后续升级BSP也不用重新merge。
2.3 旋转90度之后触摸坐标为什么必然错
这是我最想强调的一点：屏幕转了，触摸不转，坐标必然错位。
原因很简单：触摸屏报上来的是它在自己坐标系里的原始坐标，比如一颗GT911，物理上贴在屏上，x轴对应屏的短边。你把显示内容转了90度，但触摸驱动还是按原来的轴序上报，于是你点左下角，系统认为你点了左上角。
解决办法在设备树里，Rockchip的触摸节点一般支持这几个属性：
>911 { compatible = "goodix,gt911"; reg = <0x5d>; interrupt-parent = <&gpio3>; interrupts = <RK_PB2 IRQ_TYPE_LEVEL_LOW>; reset-gpios = <&gpio3 RK_PC4 GPIO_ACTIVE_LOW>; irq-gpios = <&gpio3 RK_PB2 GPIO_ACTIVE_HIGH>; touchscreen-inverted-x; touchscreen-inverted-y; touchscreen-swapped-x-y; };touchscreen-swapped-x-y：交换x和y轴，旋转90/270度时基本都要加。touchscreen-inverted-x/touchscreen-inverted-y：把某个方向翻过来，对应旋转180度或者镜像的情况。
90度和270度的区别，往往就体现在这两个inverted上。我的做法是准备四个组合（swapped关/inverted全关，swapped开/inverted-x开，swapped开/inverted-y开，swapped开/inverted全关），烧一遍试一次，一般两轮就能定下来。
实操心得：如果面板方向是竖屏，但你要显示横屏内容，那么显示旋转和触摸旋转必须是"同向抵消"的。很多人只改显示不改触摸，就会出现"点哪都不对"的诡异现象。定位这类问题时，最快的办法是在开发者选项里打开"指针位置"，直接看触点坐标跑哪去了。
3. 分辨率：DTS固定时序与运行时wm size的边界
分辨率这块，我见过太多人一上来就去搜"RK3588怎么改分辨率"，然后被一堆wm size的答案带偏。wm size是调试用的，不是量产的方案。真正决定分辨率的是设备树里的panel-timing。
3.1 从panel-timing反推像素时钟
RK3588的MIPI DSI或者RGB屏，时序都写在panel-timing节点里。以一个1024x600的MIPI屏为例：
display-timings { native-mode = <&timing0>; timing0: timing0 { clock-frequency = <51200000>; /* 51.2MHz */ hactive = <1024>; hfront-porch = <160>; hback-porch = <160>; hsync-len = <10>; vactive = <600>; vfront-porch = <12>; vback-porch = <23>; vsync-len = <1>; hsync-active = <0>; vsync-active = <0>; de-active = <0>; pixelclk-active = <0>; }; };这几个数不能随便填，它们之间是有关联的。像素时钟的计算公式是：
h_total = hactive + hfront-porch + hback-porch + hsync-len v_total = vactive + vfront-porch + vback-porch + vsync-len clock-frequency ≈ h_total × v_total × 刷新率拿上面的数代进去：
h_total = 1024 + 160 + 160 + 10 = 1354 v_total = 600 + 12 + 23 + 1 = 636 刷新率 = 51200000 / (1354 × 636) ≈ 59.45 Hz差不多60Hz，合理。如果你把clock-frequency改成65000000而不动其它参数，刷新率会飙到75Hz左右，屏可能不亮或者抖动。所以改分辨率的时候，必须同时按屏厂规格书重算这几组param，而不是只改hactive/vactive。
3.2 wm size只是改了逻辑尺寸，不是改了屏
wm size这个命令很多人当救命稻草用，但它做的事只有一件：告诉SurfaceFlinger"我认为屏幕是这么大"。
# 查看当前逻辑分辨率 adb shell wm size # 输出类似：Physical size: 1024x600 # 临时改成1280x800 adb shell wm size 1280x800 # 恢复 adb shell wm size reset改了之后会发生什么？SurfaceFlinger会把合成输出从1280x800缩放到1024x600的物理帧上。画面不会更清晰，只会更糊，而且触摸坐标也要跟着换算。所以wm size只适合在调试阶段快速验证布局，绝对不能作为量产方案。
真正需要改物理分辨率的时候，你要动的是panel-timing。而如果你用的是HDMI输出，那就更简单——HDMI走的是EDID协商，Rockchip的DRM驱动会读显示器的EDID，自动挑一个支持的模式。想强制指定HDMI分辨率，就在设备树或者命令行里指定mode，比如：
# 查看HDMI支持的模式 cat /sys/class/drm/card0-HDMI-A-1/modes # 运行时强制指定 adb shell settings put global hdmi_resolution 1920x10803.3 VOP带宽和分辨率上限的实际约束
RK3588有VOP2/VOP3，多路输出。每一路输出都有带宽限制，同时开多屏大分辨率的时候容易碰到天花板。
大概的经验值是：单个VOP图层在1920x1080@60Hz以内比较稳，4K@60Hz需要走VOP3或者专门的通道。如果同时开HDMI 4K和MIPI 1080p，再加上多个视频图层叠加，就可能出现撕裂、掉帧、甚至VOP报错。
排查这个最直接的工具是Rockchip提供的debugfs：
cat /sys/kernel/debug/dri/0/summary这个输出会列出当前VOP的配置，包括每个plane的分辨率、格式、是否启用。如果你看到某个plane的格式是XR24这种带alpha的大格式，又会显著增加带宽消耗。降带宽最有效的三招：减少叠加层数、缩小分辨率、把不透明图层换成RGB565这类低带宽格式。
注意：VOP的带宽不是只算最终的显示分辨率，而是所有参与合成的图层加在一起。一个全屏背景加两个半屏视频窗口，实际带宽可能比单开4K还高。这是我在做多窗口视频墙项目时踩过的坑——单屏测试丝滑，三窗口一起开就掉帧。
4. density给多少才合适：从PPI算起，别凭感觉填
密度这个参数，很多人随手填240或者320，结果界面要么巨大要么小到看不清。其实density是有计算依据的，它来源于屏幕的PPI。
4.1 手算PPI并映射到Android density档位
PPI的计算公式是：
PPI = sqrt(水平像素² + 垂直像素²) / 屏幕对角线英寸数Android的density档位大致对应：
| density值 | 档位名 | 典型PPI范围 |
|---|---|---|
| 120 | ldpi | ~120 |
| 160 | mdpi | ~160 |
| 213 | tvdpi | ~213 |
| 240 | hdpi | ~240 |
| 320 | xhdpi | ~320 |
| 480 | xxhdpi | ~480 |
| 640 | xxxhdpi | ~640 |
举几个RK3588项目里常见的屏：
- 7寸 1024x600：
sqrt(1024² + 600²) / 7 = 1186.8 / 7 ≈ 169.5→ 取160或240，看你的UI设计基准。 - 8寸 1280x800：
1509.4 / 8 ≈ 188.7→ 常用213或240。 - 10.1寸 1280x800：
1509.4 / 10.1 ≈ 149.4→160比较合适。 - 15.6寸 1920x1080：
2202.9 / 15.6 ≈ 141.2→160。 - 21.5寸 1920x1080：
2202.9 / 21.5 ≈ 102.5→120或160。
这里有个经验法则：PPI算出来之后，向下取最近的档位，通常比向上取更好用。因为向上取（比如169取240）会让界面元素整体放大，一屏显示的东西变少；向下取（169取160）界面更紧凑，但对触摸精度要求高一点。工业控制屏我一般取大一号，看得清；消费平板我取小一号，信息密度高。
4.2 ro.sf.lcd_density和wm density的作用范围差异
和分辨率一样，density也有两层。
ro.sf.lcd_density是只读属性，在开机时被SurfaceFlinger读取，作为初始density。它写在system.prop或者device.mk里：
PRODUCT_PROPERTY_OVERRIDES += \ ro.sf.lcd_density=240wm density是运行时的：
# 查看 adb shell wm density # 修改 adb shell wm density 240 # 恢复 adb shell wm density reset二者的关系是：wm density会写到persist.sys.display.density，覆盖掉ro.sf.lcd_density的初始值。所以调试阶段用wm density快速试，确定之后就写回ro.sf.lcd_density，这是标准流程。
提示：改完density之后，有些系统应用（尤其是Launcher和Settings）需要重启进程才能完全生效，
adb shell am force-stop com.android.settings比整个重启快得多。
4.3 改完density布局跑偏的定位顺序
改density之后如果界面乱了，别急着回退，按这个顺序查：
- 先确认density真的生效了：
adb shell wm density看输出，是不是你设的值。 - 确认是不是
smallestWidth问题：很多应用会根据sw<N>dp加载不同布局。density变了，sw也跟着变，可能从sw600dp跳到了sw720dp，加载了完全不同的布局文件。 - 看是不是自定义View写死了px：这是最常见的坑。如果你的应用里大量用
px而不是dp，density一变全乱。这种问题改density是治标，改代码才是治本。 - 确认系统UI也一起变了：状态栏、导航栏的高度是按density算的，如果只有应用变了系统没变，说明有地方缓存了旧值。
我自己的项目里现在都强制一条规矩：所有布局尺寸一律用dp和sp，硬编码px的代码在review阶段直接打回。踩过两次这种坑之后，density改动就是改一个数字的事，再也不用担心布局。
5. 多屏与产品差异化：别把公共代码改成私货
RK3588最大的卖点之一就是能同时驱动多路显示，但这也带来了一个新问题：主屏和副屏的分辨率、方向、密度往往是不同的，而Rockchip的公共代码只能给一套默认值。
5.1 主屏副屏的分辨率、方向独立配置
在设备树这一层，每一路输出都有自己的节点，天然是独立的：
/* MIPI DSI0 主屏 */ &dsi0 { status = "okay"; }; &dsi0_in_vp0 { status = "okay"; }; /* HDMI0 副屏 */ &hdmi0 { status = "okay"; }; &hdmi0_in_vp1 { status = "okay"; };分辨率分别在各自的panel-timing（MIPI）和EDID（HDMI）里决定。方向则要看HWC怎么处理——ro.sf.hwrotation是全局的，对多屏来说就不太够用了。这时候一般有两种做法：
- 软件层处理：由应用自己感知是哪块屏，分别设置窗口朝向。
- 改HWC逻辑：让HWC根据display id来决定是否旋转。这需要改
hardware/rockchip/hwcomposer下的代码，工作量大但一劳永逸。
如果不是必须两屏都竖屏，我的建议是能不动HWC就不动，优先用应用层适配，改动可控、升级友好。
5.2 HDMI热插拔时的参数重协商
HDMI是可以热插拔的，插上之后DRM会重新读EDID，协商出一个新的分辨率。这个过程会触发一次hotplug事件，SurfaceFlinger收到后要重新配置DisplayDevice。
这里有三个常见的坑：
- 插上HDMI之后主屏花屏：往往是VOP的VP分配冲突了，两个输出抢了同一个VP。要检查
dsi0_in_vp0、hdmi0_in_vp1这些绑定关系。 - 拔掉HDMI之后应用崩溃：应用没有处理
onDisplayRemoved回调，还在往已经消失的Display上画。 - 热插拔后density变了：HDMI的density有时候是按EDID里的物理尺寸算的，如果EDID没写清楚，会算出一个奇怪的值。可以在框架层强制覆盖。
5.3 用overlay和产品级配置隔离改动
这是我最想推荐的一条工程实践：别直接改Rockchip的公共代码，用产品级的overlay和配置覆盖。
具体怎么做：
- 目录结构上，每个产品建一个自己的目录，比如
device/rockchip/rk3588/product_a/。 - 系统属性写在
product_a/system.prop，通过PRODUCT_PROPERTY_OVERRIDES引入。 - 资源覆盖（比如
config_defaultRotation）用RRO（Runtime Resource Overlay）或者编译时overlay。 - 设备树用
rk3588-product_a.dts，只在产品自己的dts里改屏相关的节点。
这样做的好处是：Rockchip更新BSP的时候，你在公共代码里没有diff，merge起来几乎没有冲突。我做过一个项目，前期图省事直接改了公共的system.prop，后来BSP从Android 12升到13，光是解冲突就花了两天，血泪教训。
6. 实机验证：参数到底生效没有，用这几条命令说话
改完参数烧录，最怕的就是"看起来没问题"。要确认参数真的生效了，得靠命令去验证，而不是靠眼睛看。
6.1 debugfs和dumpsys的交叉验证
我常用的验证组合是这几条：
# 1. 看VOP实际配置（分辨率、格式、plane） cat /sys/kernel/debug/dri/0/summary # 2. 看SurfaceFlinger认为的显示参数 adb shell dumpsys SurfaceFlinger | grep -A 20 "DisplayDeviceInfo" # 3. 看WindowManager里屏幕的实际尺寸和density adb shell dumpsys display | grep -E "mBaseDisplayInfo|density|DisplayInfo" # 4. 看当前朝向 adb shell dumpsys window | grep -E "mRotation|mLastOrientation"dri/0/summary这个输出特别有用，它会明确告诉你VOP当前输出的mode是不是你DTS里写的那个。如果这里显示的模式和你配置的不一样，那说明在DTS这一层就没生效，改Android属性也没用。
我遇到过一次，DTS改了分辨率，但summary里还是旧的。查了半天发现是设备树里有多个panel节点，native-mode指错了，实际生效的是另一个。这种问题只能靠debugfs抓出来，光看代码是看不出的。
6.2 花屏、黑屏、错位的排查顺序
出现显示异常时，我有一套固定的排查顺序，从底层往上层推：
| 现象 | 优先怀疑 | 验证手段 |
|---|---|---|
| 完全不亮 | 背光、上电时序、DTS时钟 | 量背光电压，看dmesg里DSI初始化日志 |
| 花屏、雪花 | 时序参数错误、lane配置 | 核对panel-timing和屏厂规格书 |
| 颜色不对 | 像素格式、DE/HSYNC极性 | 检查de-active、pixelclk-active |
| 图像偏移 | porch参数不对 | 微调hback-porch/vback-porch |
| 方向错 | HWC旋转配置 | 看ro.sf.hwrotation |
| 触摸错位 | 触摸轴序配置 | 打开"指针位置"看坐标 |
这张表是我这些年攒下来的，基本覆盖了九成以上的屏问题。方向错和触摸错位是两回事，一定要分开排查，混在一起想会越查越乱。
6.3 几个我在项目里反复踩到的具体坑
最后分享几个具体的、文档里不会写的坑：
坑一：改了ro.sf.hwrotation但开机logo没转。开机logo走的是uboot和kernel的启动画面，跟Android的HWC无关。要转logo，得在uboot的显示配置里改，或者在kernel的logo节点里处理。这个我是被客户投诉了才知道的。
坑二：wm density改完，dumpsys display里看还是旧值。因为dumpsys display读的是DisplayManagerService的缓存，而density是SurfaceFlinger层改的。要看真实值，用adb shell wm density。
坑三：同一块板子，换一个批次的面板就不亮了。面板厂的固件版本不同，时序稍有差异。解决办法一是把porch参数放宽一点留余量，二是在DTS里加多个panel-timing，运行时动态选。
坑四：横屏改竖屏之后，摄像头预览拉伸。摄像头预览的尺寸是独立的，跟屏幕方向没关系，但应用如果用了全屏预览，就会跟着屏幕比例变。这种问题要在Camera的preview size里单独配。
坑五：多屏的时候，ro.sf.lcd_density对HDMI副屏也生效了。结果主屏正常，副屏字大得离谱。这种场景下要在应用层用Configuration分别处理，或者改HWC让每个display各自取density。
说到底，RK3588的屏幕配置不是"改一个数字"的事，而是要顺着VOP、HWC、SurfaceFlinger、WindowManager这条链，搞明白每个参数各自在哪儿说话。我现在的习惯是，新项目点屏的时候，先在一张纸上把这几层画出来，把每个要改的参数标到对应的层上，然后从下往上改、从下往上验。这样虽然前期慢一点，但基本不会出现"改了半天发现方向没对，其实是触摸没对"这种返工。毕竟板子烧一次要等好几分钟，思路清楚比手快重要得多。
