fix: restore USB device enable/disable after driver cleared - #767
Merged
deepin-bot[bot] merged 1 commit intoSep 18, 2026
Merged
Conversation
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Reviewer's guide (collapsed on small PRs)Reviewer's GuideRestores enable/disable controls for USB devices that report usbfs after being disabled by replacing the cleared driver with a usb fallback for USB system paths, while preserving the existing usbfs filtering behavior. Sequence diagram for restoring USB device enable and disable controlssequenceDiagram
participant DeviceManager
participant DeviceOthers
participant TableWidget
DeviceManager->>DeviceOthers: setInfoFromLshw(mapInfo)
DeviceOthers->>DeviceOthers: setAttribute(mapInfo, "logical name", m_LogicalName)
alt m_Driver is usbfs
DeviceOthers->>DeviceOthers: m_Driver.clear()
alt m_SysPath contains usb
DeviceOthers->>DeviceOthers: m_Driver = "usb"
end
end
alt m_Driver is empty and m_Avail is not yes
DeviceOthers->>DeviceOthers: setForcedDisplay(true)
else USB fallback driver is present
DeviceOthers->>DeviceOthers: setCanEnable(true)
TableWidget->>TableWidget: Show enable or disable action
end
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
deepin pr auto review🤖 AI 代码审查报告总体评分： 📊 总体评价
🔍 详细分析1. 语法逻辑 ❌评价： 一般 ❌ 不通过 潜在问题：
建议： 将条件修改为 if (m_Driver.isEmpty() && m_SysPath.contains("usb"))，确保仅在驱动被清空后才设置回退值 "usb"，避免覆盖设备的真实驱动信息 2. 代码质量 ✅评价： 优秀 ✅ 通过 潜在问题：
建议： 在新增代码块前添加注释，说明该逻辑为 USB 设备 usbfs 驱动清除后的回退处理，避免后续维护时产生困惑 3. 代码性能 ✅评价： 优秀 ✅ 通过 潜在问题： 建议： 性能良好，QString::contains() 操作开销极小，无性能瓶颈 4. 代码安全 🔒评价： 优秀 ✅ 通过
安全漏洞详情： 建议： 无安全风险，代码处理的是系统设备信息，不涉及用户输入或外部数据 💡 改进建议代码示例// 正确的修复方式：仅在驱动为空时设置回退值
if (m_Driver.toLower() == "usbfs")
m_Driver.clear();
// 仅当驱动被清空后，为USB设备设置回退驱动值，避免覆盖真实驱动
if (m_Driver.isEmpty() && m_SysPath.contains("usb")) {
m_Driver = "usb";
}本报告由 AI 代码审查工具自动生成 |
1. Root cause: setInfoFromLshw() clears driver when lshw reports "usbfs", leaving it empty; empty driver plus avail=="yes" triggers setCanEnable(false), hiding the enable/disable button in context menu 2. Fix: after clearing usbfs driver, check if m_Driver is empty and m_SysPath contains "usb", then set m_Driver to "usb" as fallback, preventing the empty-driver condition 3. Impact: USB devices (cameras, etc.) retain enable/disable button after being disabled; non-USB devices unaffected; usbfs clearing logic preserved (bug 333969 fix intact) Log: Fix USB device unable to re-enable after being disabled Influence: 1. Test USB camera disable then re-enable via context menu 2. Test non-USB other devices display and enable/disable behavior 3. Verify usbfs driver values are still filtered from display fix: 修复USB设备禁用后无法再次启用的问题 1. 根因：setInfoFromLshw() 在 lshw 报告驱动为 "usbfs" 时清除驱动 值，导致驱动为空；空驱动且 avail 为 "yes" 时触发 setCanEnable(false)，右键菜单中启用/禁用按钮消失 2. 方案：清除 usbfs 驱动后，检查 m_Driver 是否为空且 m_SysPath 包含 "usb"，若是则设置 m_Driver 为 "usb" 作为回退值，避免驱动为空 3. 影响：USB 设备（摄像头等）禁用后保留启用/禁用按钮；非 USB 设备不受影响；usbfs 清除逻辑保留（bug 333969 修复不受影响） Log: 修复USB设备禁用后无法再次启用的问题 Influence: 1. 测试USB摄像头禁用后通过右键菜单重新启用 2. 测试非USB其他设备的显示和启用/禁用功能 3. 验证usbfs驱动值仍被正确过滤不显示 PMS: BUG-377341
add-uos
force-pushed
the
agent/pms-bug-bot/c902f05603ed
branch
from
September 18, 2026 02:12
711a1bb to
4d21b71
Compare
lzwind
approved these changes
Sep 18, 2026
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: add-uos, lzwind 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 |
Contributor
Author
|
/merge |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Root Cause Analysis
In
DeviceOthers::setInfoFromLshw(), when lshw reports a device driver as "usbfs", the code clears it to an empty string. If the driver is then empty and the device'scfg_availis "yes",setCanEnable(false)is called, which causes the enable/disable button to disappear from the context menu inTableWidget. This primarily affects USB devices (e.g., cameras) that report "usbfs" as their driver after being disabled — users can no longer re-enable them without rebooting.Key evidence:
DeviceOthers.cpp:46-51(usbfs clearing → empty driver → setCanEnable(false)),TableWidget.cpp:285-289(canEnable controls button visibility).Fix
After clearing the "usbfs" driver value, check if
m_Driveris empty ANDm_SysPathcontains "usb", then setm_Driver = "usb"as a fallback. TheisEmpty()guard ensures existing valid drivers are not overwritten. SPDX copyright year updated to "2022 - 2026" inDeviceOthers.cpp. OnlyDeviceOthers.cppis modified —DeviceOthers.his not touched.Change Safety Assessment
Code Safety
usbfsclearing behavior (commit4cc56848, PMS bug 333969) is preserved — only a fallback value is added for USB devices when driver is emptyisEmpty()guard prevents overwriting valid driver values from lshwsetInfoFromLshw()andsetCanEnable()remain compatible:DeviceManager.cpp:1672(caller),TableWidget.cpp:285-289(consumer of canEnable)Business Impact Scope
Affected module: Other Devices management — USB device enable/disable functionality in Device Manager. After the fix, USB devices (cameras, etc.) that report "usbfs" driver will retain their enable/disable button after being disabled. Non-USB devices are unaffected.
Verification Suggestion
Test USB camera disable then re-enable via right-click context menu; verify non-USB other devices are unaffected; confirm usbfs driver values are still filtered from device info display.
根因分析
DeviceOthers::setInfoFromLshw()中，当 lshw 报告设备驱动为 "usbfs" 时，代码将其清除为空字符串。如果驱动为空且设备cfg_avail为 "yes"，则调用setCanEnable(false)，导致右键菜单中的启用/禁用按钮消失。这主要影响禁用后报告 "usbfs" 驱动的 USB 设备（如摄像头）——用户无法重新启用，只能重启系统。关键证据：
DeviceOthers.cpp:46-51（usbfs 清除 → 空驱动 → setCanEnable(false)），TableWidget.cpp:285-289（canEnable 控制按钮显示）。修复方案
清除 "usbfs" 驱动值后，检查
m_Driver是否为空且m_SysPath是否包含 "usb"，若是则设置m_Driver = "usb"作为回退值。isEmpty()前置判断确保不会覆盖 lshw 报告的有效驱动值。DeviceOthers.cpp的 SPDX 版权年份更新为 "2022 - 2026"。仅修改DeviceOthers.cpp，不修改DeviceOthers.h。改动安全评估
代码安全评估
4cc56848，PMS bug 333969）被保留——仅在驱动为空时为 USB 设备添加回退值isEmpty()前置判断防止覆盖 lshw 报告的有效驱动值setInfoFromLshw()和setCanEnable()的所有调用者均兼容：DeviceManager.cpp:1672（调用方），TableWidget.cpp:285-289（canEnable 消费方）业务影响范围
受影响模块：其他设备管理——设备管理器中 USB 设备的启用/禁用功能。修复后，报告 "usbfs" 驱动的 USB 设备（摄像头等）在禁用后仍保留启用/禁用按钮。非 USB 设备不受影响。
验证建议
测试 USB 摄像头禁用后通过右键菜单重新启用；验证非 USB 其他设备不受影响；确认 usbfs 驱动值仍被正确过滤不显示。
PMS: BUG-377341