[{"content":"","date":"2026年8月5日","externalUrl":null,"permalink":"/tags/a133/","section":"Tags","summary":"","title":"A133","type":"tags"},{"content":" 1. 环境 # 平台：A133 系统环境：Android 11 芯片：gsl5680 2. 调试背景 # gs5680是一款思立微TP触摸芯片，支持16寸的电容屏，同时向下兼容小尺寸屏幕，主要看通道数，比如一般来说16寸屏幕通道数是大于14寸，所以能支持16寸就可以支持14寸，大于16寸是否支持需要询问fae。\n3. 调试过程 # 3.1 底层驱动 # 事先要配置好驱动文件（gslx680new），最终实现效果是能使用i2cdetect查看到对应地址，并且成功加载驱动注册ipnut_dev即可，这时候一般触摸效果是不行的，触摸芯片工作异常，所以要让fae现场调效。\n3.2 现场调效 # 现场调效的话主要是fae负责，我们重点说明一下如何使用这个fae提供的效果文件。\n(1) 文件格式转换 # 一般fae提供的效果文件为xxxx.h，而全志内置gs65680驱动使用的是xxxx.bin文件，我们需要使用工作将.h转换成.bin文件。\n工具目录：vendor/aw/public/package/bin/gsltool 通过mm编译工具，然后执行gsltool gslX680_3676_10inch firmware/将gslX680_3676_10inch.h转换成gslX680_3676_10inch.bin并放在firmware目录下\n(2) 指定使用的效果文件 # 例如上面就指定驱动使用的效果文件为gslX680_3676_10inch.bin\n(3) 打包效果文件 # 路径：device/softwinner/ceres/ceres-b6/input/config.mk\nGSLFIRMWARELIST指定打包具体的效果文件：\n指定打包的效果文件为gslX680_3676_8inch.bin 和 gslX680_3676_10inch.bin\n打包脚本：gsl_firmware.mk\n具体逻辑是如果GSLFIRMWARELIST为空就打包所有.bin文件，如果GSLFIRMWARELIST有指定就只打包指定的。\n4. 问题分析 # 4.1 y轴触不到边 # 实测发现y轴触不到变，上报数据范围只有19~1178，上下都差20\n解决方法有两种：\n（1）让fae再次现场调优\n​\t注意后面验收的时候要看能不能触摸到边\n（2）修改驱动\n如上处理上报的数据，touch_min_y为实测的最小上报数据19，touch_max_y为实测的最大上报数据为1178，SCREEN_MAX_Y屏幕实测的分辨率1200，上面代码逻辑就是将[19, 1178]映射[0,1200]范围内，这样处理的好处是，提高精准度并且不损失连续性，如果是直接将y轴全部减10或者上半部分屏幕减10，下半屏幕加10，这样都会出现无效区域。\n","date":"2026年8月5日","externalUrl":null,"permalink":"/posts/gsl5680-debug/","section":"Posts","summary":"分享A133平台 gsl5680芯片调试经验","title":"A133平台 gsl5680芯片调试总结","type":"posts"},{"content":"","date":"2026年8月5日","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"2026年8月5日","externalUrl":null,"permalink":"/tags/gsl5680/","section":"Tags","summary":"","title":"Gsl5680","type":"tags"},{"content":"","date":"2026年8月5日","externalUrl":null,"permalink":"/","section":"Huang JY 技术博客","summary":"","title":"Huang JY 技术博客","type":"page"},{"content":"","date":"2026年8月5日","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"2026年8月5日","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"2026年8月5日","externalUrl":null,"permalink":"/tags/tp/","section":"Tags","summary":"","title":"TP","type":"tags"},{"content":"","date":"2026年8月5日","externalUrl":null,"permalink":"/categories/%E8%B0%83%E8%AF%95%E7%BB%8F%E9%AA%8C/","section":"Categories","summary":"","title":"调试经验","type":"categories"},{"content":"","date":"2026年8月5日","externalUrl":null,"permalink":"/tags/%E5%85%A8%E5%BF%97/","section":"Tags","summary":"","title":"全志","type":"tags"},{"content":"","date":"2026年7月31日","externalUrl":null,"permalink":"/tags/a527/","section":"Tags","summary":"","title":"A527","type":"tags"},{"content":"","date":"2026年7月31日","externalUrl":null,"permalink":"/tags/uvc%E6%91%84%E5%83%8F%E5%A4%B4/","section":"Tags","summary":"","title":"UVC摄像头","type":"tags"},{"content":" 1. 环境 # 平台：a527 安卓环境：android13 硬件：800x800@30fps mjpeg格式uvc摄像头 2. 问题描述 # 2.1. 现象演示 # 在都不获取图像的情况下a83t和a527的功耗基本一样，获取图像之后，a527功耗比a83t大1W。跟客户沟通知道，a83t使用硬解码，a527使用库进行软件解码。\n2.2. 过程描述 # 在a527平台使用客户app（软解）和AWcamrea2（硬解）进行对比：\n客户app获取uvc摄像头功耗高，cpu占用率高，cpu带宽高\nAWcamrea获取uvc摄像头功耗低，cpu占用率低，cpu带宽低\n软件通路：\n客户app获取uvc摄像头通路：usb控制器-\u0026gt;uvc-driver-\u0026gt;v4l2框架\u0026ndash;\u0026gt;第三方库解码（软解码）\u0026ndash;\u0026gt;app\nAWcamrea获取uvc摄像头：usb控制器-\u0026gt;uvc-driver-\u0026gt;v4l2框架\u0026ndash;\u0026gt;usb camrea hal(调用VE进行硬件解码)\u0026mdash;\u0026gt;app\n2.3. 图片及说明 # 使用cpu_monitor可知道，客户app整体占用率较高，并且后面CPU4、5、6大核占用率高。\n使用mtop可知道带宽有变化，下面红色方框为客户app（软解）：\n3. 结果 # 3.1. 原因分析 # 硬解码是用过硬件电路进行解码，功耗低，cpu占用率低，cpu带宽低\n软解码是通过cpu运算进行解码的，功耗高，cpu占用率高，cpu带宽高\n3.2. 解决方法 # （1）调试usb摄像头，使得原生AWcamera2能获取uvc摄像头数据\n（2）客户app直接内部调用原生AWcamera2\n4. FAQ # 4.1 如何知道使用了VE硬件编码 # （1）看VE的clk有没有开\ncat /sys/kernel/debug/clk/clk_summary | grep ve\n（2）看相关服务有没有开启\nlsof | grep \u0026quot;cedarc_dev\u0026quot;\n（3）mtop -m\n看ve_rw带宽有没有占用\n需要注意的是，不同平台的ve_xx名称可能不一样，名称对应才能统计带宽\n在板级设备树中进行确认真实名字：\n如果名字不同，需要修改mtop源码统计名称\n跳转命令：gomod mtop\n4.2 如何获取HAL的日志 # logcat获取\n可以使用LOG_TAG进行过滤，一般在hal文件的第一行会有个tag，在日志搜这个tag就能找出这个文件的相关打印\n","date":"2026年7月31日","externalUrl":null,"permalink":"/posts/uvc-swdecode-power/","section":"Posts","summary":"分析UVC摄像头软解码导致功耗高问题","title":"UVC摄像头软解码导致功耗高问题分析","type":"posts"},{"content":"","date":"2026年7月31日","externalUrl":null,"permalink":"/tags/%E5%8A%9F%E8%80%97/","section":"Tags","summary":"","title":"功耗","type":"tags"},{"content":"","date":"2026年7月31日","externalUrl":null,"permalink":"/tags/%E8%A7%A3%E7%A0%81/","section":"Tags","summary":"","title":"解码","type":"tags"},{"content":"","date":"2026年7月31日","externalUrl":null,"permalink":"/categories/%E9%97%AE%E9%A2%98%E5%88%86%E6%9E%90/","section":"Categories","summary":"","title":"问题分析","type":"categories"},{"content":"","date":"2026年7月29日","externalUrl":null,"permalink":"/tags/gpadc/","section":"Tags","summary":"","title":"GPADC","type":"tags"},{"content":"本文记录一次 A133 平台使用GPADC作为Lsensor实现自动背光的调试过程。\n1. 调试背景 # 项目需要实现自动背光要求，鉴于成本，使用了GPADC进行替代光感，主控获取GPADC具体电压来粗劣判断外部光亮强度。\n功能链路如下：\n具体原理图如下：\nDDR-PARA-SEL-ADC连接到主控GPADC1，可以通过R1355来调节灵敏度\nGPADC支持输入电压范围为0~1.8V\n2. 底层配置 # 2.1移植驱动 # 当前WSDK-A133_AndroidR_v2.3找不到GPADC（sunxi_gpadc.c）驱动，所以需要在A133其他SDk移植GPADC驱动。\n2.2 自动加载驱动 # 配置自动加载驱动（sensor_modules.cfg）：\n​ID_L代表这个为Lsensor驱动\n2.3 添加设备书节点 # 添加设备节点：\n设备树具体含义：\n可以知道1——\u0026gt;01(二进制) 代表使用GPADC0 2——\u0026gt;10(二进制) 代表使用GPADC1\n使用cat /proc/bus/input/devices验证驱动通路：\n通路配置已经完成了，但是数据上报功能依旧是异常的，默认只支持key上报，所以我们要在sunxi_gpadc基础上改造驱动：\n驱动上报的数据类型是ABS_MISC。\n使用getevent -l 验证数据上报是否正确：\n3. 适配HAL层 # 3.1添加设备信息 # 3.2添加支持light的feature # 使用pm list features | grep light验证:\n使用dumpsys sensorservice验证HAL层是否正常：\n可以看到sunxi GPADC，初步看hal层是没问题的\n继续看有无数据上报：\n注意要开启自动背光或者使用第三方软件获取数据，不然是没有数据显示的。\n到这里HAL层也正常了\n4. 修改映射表 # config_autoBrightnessDisplayValuesNits为亮度，config_autoBrightnessLevels为HAL上报的数据。\n需要注意：config_autoBrightnessDisplayValuesNits有16列，config_autoBrightnessLevels有15列，所以不是一一对应的关系，而是环境亮度[0,20]-\u0026gt;背光[0，50]，并且Andorid 11背光调节带有用户偏好机制，不是简单的线性调节。\n5.问题 # 5.1 自动背光调节响应速度慢 # 默认响应速度为较长，参考修改：\n将响应速度调整为2秒\n","date":"2026年7月29日","externalUrl":null,"permalink":"/posts/gpadc-to-lsensor/","section":"Posts","summary":"介绍","title":"GPADC代替Lsensor实现自动背光调试总结","type":"posts"},{"content":"","date":"2026年7月29日","externalUrl":null,"permalink":"/tags/lsensor/","section":"Tags","summary":"","title":"Lsensor","type":"tags"},{"content":"","date":"2026年7月29日","externalUrl":null,"permalink":"/tags/hal/","section":"Tags","summary":"","title":"HAL","type":"tags"},{"content":" 1. 环境 # 平台：A133 系统环境：Android 11 屏幕：EDP 1920x1200 2. 问题描述 # 正常情况下屏幕显示正常，切换到特定界面会出现轻微闪烁。\n正常界面：\n点击贝果可以切换到异常界面\n异常界面：\n闪烁只是轻微闪烁，现象类似是背光出现明暗变化。\n3. 结果 # 3.1 原因分析 # （1）背光排查 # 因为现象类似是背光出现明暗变化，所以优先排查背光问题。\n屏幕pwm输入频率范围：\n主控输出为pwm频率为1K满足需求\n排查背光电路问题：\n使用直流源代替VCC-5V供电，依旧出现闪烁问题，所以基本排除背光影响。\n（2）DE排查 # 因为屏幕分辨率为1920x1200，怀疑DE频率不够\n使用cat /sys/class/disp/disp/attr/sys可以查看de频率\n默认de频率为300000000HZ：\n改为600000000HZ：\n闪烁依旧出现，排除带宽不够导致的。\n（3）hwc-hal层排查 # 使用hwcdebug -o layer; logcat -s sunxihwc抓log:\n看到有一帧为GPU合成，之后又切回硬件合成这个过程gpu合成帧及硬件合成帧可能不连续，所以看到闪一下。\n3.2 解决方法 # 禁止该场景下切换GPU合成：\n开发者模式GPU合成，但是可能会在复杂情况下掉帧：\n综合考虑使用屏蔽GPU合成策略\n","date":"2026年7月29日","externalUrl":null,"permalink":"/posts/display-hal-flicker/","section":"Posts","summary":"分析图层合成导致闪屏问题","title":"图层合成策略导致闪屏问题分析","type":"posts"},{"content":"","date":"2026年7月29日","externalUrl":null,"permalink":"/tags/%E6%98%BE%E7%A4%BA/","section":"Tags","summary":"","title":"显示","type":"tags"},{"content":"","date":"2026年7月28日","externalUrl":null,"permalink":"/tags/lradc/","section":"Tags","summary":"","title":"LRADC","type":"tags"},{"content":" 1. 环境 # 平台：A133 系统环境：Android 11 2. 问题描述 # 按键按下不无效\n3. 结果 # 3.1 原因分析 # 常态电压为1.8V，音量加按键按下为0V，音量减按键按下为1.2V，实测LRADC按键音量减按键不生效。\n设备树配置配置：\n可知已经配置成对应电压了，按键依旧不生效。\n查看A133芯片手册:\n可以知道A133 lradc最大检测电压为1.35V，理应是可以识别1.2V电压的。\n发现是驱动默认将LRADC_CTRL寄存器的[4:5]设置成10：\n10代表最大可识别电压为1.139V，按键按下的1.2V电压超出识别范围，所以按键不生效。\n3.2 解决方法 # 修改驱动（sunxi-keyboard.c）：\n原先函数：\n参考修改：\n将LRADC_CTRL寄存器的[4:5]设置为00，即可识别1.2V电压。\n","date":"2026年7月28日","externalUrl":null,"permalink":"/posts/lradc-button-not-functioning/","section":"Posts","summary":"分析LRADC按键无效问题","title":"LRADC按键无效问题分析","type":"posts"},{"content":"","date":"2026年7月28日","externalUrl":null,"permalink":"/tags/%E6%8C%89%E9%94%AE/","section":"Tags","summary":"","title":"按键","type":"tags"},{"content":"","date":"2026年7月23日","externalUrl":null,"permalink":"/tags/hdmi/","section":"Tags","summary":"","title":"Hdmi","type":"tags"},{"content":" 1. 环境 # 平台：A527 系统环境：Android 13 2. 问题描述 # 2.1 现象演示 # 开机过程中出现短暂无信号过程，表现为蓝屏或者黑屏（根据屏幕的无信号现象），定位是在 U-Boot 到内核的过渡阶段。\n2.2 过程描述 # 开机即可 100% 出现。\n2.3 附录图片 # 示波器抓到的型号波形图，中间为无信号现象。\n3. 结果 # 3.1 原因分析 # 通过 logcat 查看日志发现：\ni2cm 是 HDMI 类似于 I2C 的通信失败，导致 HDMI DDC 获取 EDID 失败，进而造成演出无信号。\n3.2 解决方法 # 修改底板设计，直接接 5V 上拉，不要进行电平转化。\n","date":"2026年7月23日","externalUrl":null,"permalink":"/posts/hdmi-boot-signal-loss/","section":"Posts","summary":"分析HDMI 开机中途短暂无信号问题","title":"HDMI 开机中途短暂无信号问题","type":"posts"},{"content":"","date":"2026年7月23日","externalUrl":null,"permalink":"/tags/%E9%BB%91%E5%B1%8F/","section":"Tags","summary":"","title":"黑屏","type":"tags"},{"content":"","date":"2026年7月23日","externalUrl":null,"permalink":"/tags/%E5%BC%80%E6%9C%BA%E5%8A%A8%E7%94%BB/","section":"Tags","summary":"","title":"开机动画","type":"tags"},{"content":" 1. 环境 # 平台：A527 系统环境：Android 13 2. 问题描述 # 开机动画结束之后到进入桌面的过程中出现黑屏，非首次开机时依旧存在。\n3. 结果 # 3.1 原因分析 # 问题由开机动画压缩包的压缩等级过高导致。\n3.2 解决方法 # 重新压缩开机动画压缩包，并将压缩等级设置为 0 - 仅存储。\n","date":"2026年7月23日","externalUrl":null,"permalink":"/posts/black-screen-after-boot-animation/","section":"Posts","summary":"分析非首次开机动画结束之后到进入桌面的过程中出现黑屏问题","title":"开机动画结束之后黑屏问题分析","type":"posts"},{"content":"","date":"2026年7月23日","externalUrl":null,"permalink":"/tags/%E6%97%A0%E4%BF%A1%E5%8F%B7/","section":"Tags","summary":"","title":"无信号","type":"tags"},{"content":"本文记录一次 A133 平台调试 CS5523 转换芯片的过程以及相关经验。项目中 A133 主控本身不直接输出 eDP 信号，因此采用 CS5523 将 A133 输出的 MIPI DSI 信号转换为 eDP 信号，再连接到 eDP 屏幕。\n1. 调试背景 # 项目显示链路如下：\nA133 显示输出侧配置为 MIPI DSI，CS5523 负责完成协议转换。\n调试时需要同时关注三部分：\nA133 侧 MIPI DSI 输出参数。 CS5523 转换芯片初始化参数。 eDP 屏幕本身的规格参数。 如果三者任意一处配置不匹配，都可能导致黑屏、闪屏、颜色异常、花屏、背光异常等问题。\n2. eDP 屏幕配置查看 # 调试 CS5523 前，需要先确认 eDP 屏幕规格。重点关注以下参数：\n分辨率 刷新率 屏时序（Pixel Clock，前后肩参数） eDP lane 数 色深，常见为 6bit、8bit（6bit + FRC也配置成8bit） 背光 PWM 频率要求 2.1 屏时序 # 一般EDP屏幕规格书中不会直接给出前后肩参数： 给出的V Blanking = VFP + VBP +VSPW\n具体的前后肩参数一般会在EDID Description里面： 类似寄存器一样前几位代表什么，后几位代表什么\n2.2 色深 # 该屏幕为6bit+2FRC，所以等同于8bit屏幕。\n3. CS5523 配置 # CS5523 是 MIPI DSI 转 eDP芯片。它的配置需要同时匹配输入侧 MIPI DSI和输出侧eDP 。\n3.1 DP端配置 # 主要配置EDP屏幕时序，lan数量，以及色深。\n3.2 MIPI端匹配 # 主要配置输入端MIPI的Lane数量。\n3.3 调试方法 # CS5523分为两种模式:\n全自动模式：上电后DP/eDP端会根据屏的edid自动做linktraing握手，只要MIPI给了timing一般就可以点亮。edp端配置参数软件会自动处理，此种不适用于MIPI 3lane的情况和部分MIPI timing微调仍调不好的情况，这种模式称为全自动模式。 半自动模式：MIPI和EDP都需要使用配置工具来配置，包括MIPI的lane数和edp的timing，edp的bit数，edp的lane数，EDP的swing等，这种称为半自动模式 如果实在无法得知屏幕时序，可以尝试使用全自动模式，利用全自动模式的自动握手，然后通过CH341 USB 转 I2C 工具读取芯片内部寄存器配置。\n如果有对比样机，但是平台不同，无法得知发送的初始化配置信息，可以使用逻辑分析仪解析MIPI DP0发送的数据： 需要注意的是要将电平调整为1.8V，这样触发电压为0.9V（MIPI信号一般为1.2V左右）\n4. 屏幕驱动 # CS5523可通过两种方法进行寄存器的初始化，i2c初始化以及MIPI DP0初始化。\n0x05A,0x3A,0xFF ：\n​\tsunxi_lcd_dsi_gen_write_2para(sel,0xFF,0X3A,0X5A);\n0x7A4,0x2B,0x00（高八位）：\n​\tsunxi_lcd_dsi_gen_write_2para(sel,0x34,0x10,0x07); ​\tsunxi_lcd_dsi_gen_write_2para(sel,0xA4,0x2B,0x00);\n0x680,0x2B,0x0A：\n​\tsunxi_lcd_dsi_gen_write_2para(sel,0x34,0x10,0x06); ​\tsunxi_lcd_dsi_gen_write_2para(sel,0x80,0x2B,0x0A);\n5. 休眠唤醒黑屏问题 # 测试发现休眠唤醒黑屏，使用i2c读出来寄存器值全部为XXX，证明CS5523芯片工作不正常，排查发现唤醒之后芯片RESET电压仅有0.8V\n规格书说明该引脚正常工作下应该为1.8V： 尝试驱动添加控制，休眠输出低电平，唤醒输出高电平，问题解决： ","date":"2026年7月16日","externalUrl":null,"permalink":"/posts/cs5523-debug/","section":"Posts","summary":"分享A133 平台 CS5523 转换芯片调试经验","title":"A133 平台 CS5523 转换芯片调试总结","type":"posts"},{"content":" 1. 环境 # 平台：a527 # 系统：Android 13 # Wi-Fi 型号：AP6256 # 2. 问题描述 # 联网后 ping 一个地址，发现每隔十个包左右就会出现一次大延迟，呈周期性。\n3. 结果 # 3.1 原因分析 # 跟供应商沟通，说是周期性的延迟大概率是因为 scan 导致的，所以深入了解了一下安卓系统的 Wi-Fi scan 机制。\nWi-Fi 的扫描场景分为下面四种情况：\n亮屏情况下，在 Wi-Fi settings 界面，固定扫描，扫描时间为 10s。 亮屏情况下，在非 Wi-Fi settings 界面，二进制指数退避扫描，退避：interval * (2^n)，最小间隔 min=20s，最大间隔 max=160s。 灭屏情况下，有保存网络时，若已连接，不扫描；否则进行 PNO 扫描，即只扫描已保存的网络。最小间隔 min=20s，最大间隔 max=20s*3=60s。 无保存网络情况下，固定扫描，间隔为 5 分钟，用于通知用户周围存在可用开放网络。 因为客户的机器是不休眠的，所以只需要考虑亮屏情况下的 1、2，可以分为在 Wi-Fi settings 界面和非 Wi-Fi settings 界面。\nWi-Fi settings 设置界面 scan 修改位置 # ConfigureWifiEntryFragment.java：对应连接 Wi-Fi、输入密码时页面创建的 ScanResultUpdater。 WifiPickerTrackerHelper.java：对应进入 Wi-Fi 扫描页面时创建的 ScanResultUpdater。 文件都有SCAN_INTERVAL_MILLIS 变量：\nSCAN_INTERVAL_MILLIS = 10，所以在 Wi-Fi 设置界面的 scan 周期为 10。\n非 Wi-Fi settings 设置界面 scan 修改位置 # ​\tWifiConnectivityManager.java：\n// 这是 Wi-Fi状态 public static final int WIFI_STATE_UNKNOWN = 0; public static final int WIFI_STATE_CONNECTED = 1; public static final int WIFI_STATE_DISCONNECTED = 2; public static final int WIFI_STATE_TRANSITIONING = 3; 可以知道，当自动漫游没有被关闭的时候，屏幕开启之后，有连接依旧进行周期 scan。\n如何知道系统有无wifi scan 操作 # ​\t可以使用 logcat，然后观察 hw_scan 类似的打印来判断是否进行了 scan。\n3.2 解决方法 # 客户想要在有连接的情况下退出WIFI settings界面不进行 scan，对应第二种情况：亮屏情况下，在非 Wi-Fi settings 界面\n直接去除了自动漫游的判断，只要一有连接就直接返回。也可以在系统手动关闭漫游开关。\n","date":"2026年7月16日","externalUrl":null,"permalink":"/posts/android-wifi-scan/","section":"Posts","summary":"分析在Android13下wifi sacn机制","title":"Andorid wifi scan导致周期性出现延迟问题分析","type":"posts"},{"content":"","date":"2026年7月16日","externalUrl":null,"permalink":"/tags/android/","section":"Tags","summary":"","title":"Android","type":"tags"},{"content":"","date":"2026年7月16日","externalUrl":null,"permalink":"/tags/cs5523/","section":"Tags","summary":"","title":"CS5523","type":"tags"},{"content":" 1. 环境 # 平台：A527 框架：sunxi_disp2 2. 问题描述 # 设置hdmi输出为 4K 分辨率时出现花屏；从 720p 切换到 4K 时也会出现花屏。\n3. 结果 # 3.1 原因分析 # 查看 FAQ，判断问题是 de_freq 频率太低带宽不够导致的。\n涉及文件：disp_manager.c\n原本 de_freq 设置为 600000000，经过判断后变为 450000000。\n3.2 解决方法 # 3.2.1 设置 4K 分辨率时花屏 # 将 de_freq 改为 600000000 即可。\n3.2.2 从 720p 切换到 4K 时花屏 # 随后发现，从 720p 切换到 4K 时仍会出现花屏。\n根据代码逻辑，每次切换分辨率都会执行一次该段代码。当切换到 720p 时，de_freq 被设置为 300000000。随后由于存在以下判断条件：\nif (ic_ver \u0026gt;= 2 \u0026amp;\u0026amp; de_freq == 600000000) 后续每次执行分辨率切换时，都不会再进入该条件分支，因此 de_freq 一直被固定为 300000000。\n将条件：\nif (ic_ver \u0026gt;= 2 \u0026amp;\u0026amp; de_freq == 600000000) 修改为：\nif (ic_ver \u0026gt;= 2) 即可使每次分辨率切换时，都能根据当前分辨率重新设置 de_freq。\n","date":"2026年7月16日","externalUrl":null,"permalink":"/posts/linux-4k-resolution-hdmi-screen-blanking/","section":"Posts","summary":"分析4K hdmi分辨率下花屏问题","title":"HDMI 4k分辨率下显示花屏问题分析","type":"posts"},{"content":"","date":"2026年7月16日","externalUrl":null,"permalink":"/tags/wi-fi/","section":"Tags","summary":"","title":"Wi-Fi","type":"tags"},{"content":"","date":"2026年7月16日","externalUrl":null,"permalink":"/tags/%E8%8A%B1%E5%B1%8F/","section":"Tags","summary":"","title":"花屏","type":"tags"},{"content":"","date":"2026年7月16日","externalUrl":null,"permalink":"/tags/%E4%BF%A1%E5%8F%B7%E5%BB%B6%E8%BF%9F/","section":"Tags","summary":"","title":"信号延迟","type":"tags"}]