Repository navigation
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: add-uos The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Reviewer's GuideThe PR fixes hardware display information loss by allowing Sequence diagram for hardware EDID header validationsequenceDiagram
participant Hardware as HardwareDisplay
participant CommonTools
participant EDIDParser
participant DeviceInfo as DisplayInfo
Hardware->>CommonTools: parseEDID(isHW=true)
CommonTools->>EDIDParser: setEdid(edidStr, errorMsg, ch, false)
EDIDParser->>EDIDParser: startsWith("ff00ffffffff00ff")
EDIDParser->>EDIDParser: startsWith("ff00ffffffffffff")
alt standard or real hardware header accepted
EDIDParser-->>CommonTools: true
CommonTools->>DisplayInfo: parse display information
else header rejected
EDIDParser-->>CommonTools: false
CommonTools-->>Hardware: display information unavailable
end
Flow diagram for EDID header compatibilityflowchart TD
A["setEdid with littleEndianMode"] --> B{littleEndianMode?}
B -->|true| C["Validate 00ffffffffffff00"]
B -->|false| D["Validate ff00ffffffff00ff"]
D --> E["Validate ff00ffffffffffff"]
C --> F["Continue existing EDID parsing"]
D --> F
E --> F
C --> G["Return false on invalid header"]
D --> G
E --> G
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
1. Root cause: big endian EDID header validation only accepts the standard VESA pattern "ff00ffffffff00ff", but real hardware EDID has 0xFF at byte 7 producing "ff00ffffffffffff" which fails the check and causes display info to be lost 2. Fix: add a second startsWith check for the real hardware header pattern alongside the standard one, so both are accepted 3. Impact: only relaxes the big endian header validation in setEdid, no signature change, no effect on little endian mode or parsing logic Influence: 1. Test standard VESA EDID header parsing in big endian mode 2. Test real hardware EDID header parsing in big endian mode 3. Verify little endian mode parsing is unaffected fix: 兼容实机 EDID 大端模式头部校验 1. 根因:大端模式 EDID 头部校验仅接受标准 VESA 模式 "ff00ffffffff00ff",但实机第 7 字节为 0xFF 生成 "ff00ffffffffffff",导致校验失败、显示器信息丢失 2. 方案:在标准头部校验旁增加实机头部模式的 startsWith 检查, 两种头部均被接受 3. 影响:仅放宽 setEdid 大端模式头部校验,不改变函数签名, 不影响小端模式及后续解析逻辑 Influence: 1. 测试标准 VESA EDID 头部的大端模式解析 2. 测试实机 EDID 头部的大端模式解析 3. 验证小端模式解析不受影响 PMS: BUG-DM-DEF-001
7d09484 to
67c9918
Compare
deepin pr auto review🤖 AI 代码审查报告📊 总体评价
🔍 详细分析1. 语法逻辑 ✅评价: 语法正确,逻辑清晰 ✅ 通过 潜在问题: 建议: [] 2. 代码质量 ✅评价: 代码结构清晰,注释完整 ✅ 通过 潜在问题: 建议: ['建议将 EDID 头部魔数字符串提取为命名常量(如 kEdidHeaderBigEndian / kEdidHeaderBigEndianAlt),提升可读性和可维护性。'] 3. 代码性能 ✅评价: 性能良好,资源使用合理 ✅ 通过 潜在问题: 建议: [] 4. 代码安全 🔒评价: 存在0个安全漏洞 ✅ 通过
安全漏洞详情: 建议: [] 💡 改进建议代码示例// 建议将魔数字符串提取为常量,提升可维护性: // 在类定义或匿名命名空间中添加: // static constexpr const char *kEdidHeaderBigEndian = "ff00ffffffff00ff"; // static constexpr const char *kEdidHeaderBigEndianAlt = "ff00ffffffffffff"; // // 修改校验逻辑: // if (!edid.startsWith(kEdidHeaderBigEndian) && !edid.startsWith(kEdidHeaderBigEndianAlt)) { // errorMsg = "Error edid info in big endian mode!"; // return false; // }本报告由 AI 代码审查工具自动生成 |
fix: accept real hardware EDID header in big endian mode
standard VESA pattern "ff00ffffffff00ff", but real hardware EDID
has 0xFF at byte 7 producing "ff00ffffffffffff" which fails the
check and causes display info to be lost
pattern alongside the standard one, so both are accepted
no signature change, no effect on little endian mode or parsing
logic
Influence:
fix: 兼容实机 EDID 大端模式头部校验
"ff00ffffffff00ff",但实机第 7 字节为 0xFF 生成
"ff00ffffffffffff",导致校验失败、显示器信息丢失
两种头部均被接受
不影响小端模式及后续解析逻辑
Influence:
PMS: BUG-DM-DEF-001
Summary by Sourcery
Bug Fixes: