Skip to content

Conversation

@add-uos
Copy link
Contributor

@add-uos add-uos commented Dec 1, 2025

pick develop/eagle to master

Summary by Sourcery

Adjust device manager behavior for specific hardware types and improve robustness and code clarity across CPU, device, and threading handling.

New Features:

  • Normalize reported CPU frequency values for specific special computer types.
  • Hide usbfs as a driver in generic device information views.

Bug Fixes:

  • Prevent indefinite blocking when waiting for device info update completion by limiting the wait timeout.

Enhancements:

  • Unify board vendor flag enum naming for PGUX to a special type identifier.
  • Clean up architecture mapping initialization formatting in common utilities.
  • Clarify and align member declarations, comments, and indentation in various tool and parser headers.

- Change waitForDone(-1) to waitForDone(60000) in MainJob::updateAllDevice()
- Add 60-second timeout to prevent device manager from hanging during device info loading
- Improve application responsiveness and user experience

pick from: linuxdeepin@00f82e6

Log: Set timeout for device info loading to prevent infinite waiting
Bug: https://pms.uniontech.com/bug-view-331983.html
Change-Id: Iab0310719df4cfa7e13176975ee0db59572d88ce
Modified CPU frequency display for kSpecialType6 devices
include current frequency and max frequency to correct hardware reporting inaccuracies.

Log: Fix CPU frequency display for special device type
Task: https://pms.uniontech.com/task-view-381765.html
Change-Id: I3a715b263868c6825ee42941b64a7c5de6a53035
Enhanced readability of the architecture mapping table by reformatting
the static QMap initialization with proper indentation and line breaks.
also add comments for variables.

Log: Refactor architecture mapping code style
Change-Id: Iea19f9e13e7b8f59f66d34877e555994832a0221
Modified CPU frequency display for kSpecialType5 devices
include current frequency and max frequency to correct hardware
reporting inaccuracies.

Log: Fix CPU frequency display for special device type
Task: https://pms.uniontech.com/task-view-381921.html
Change-Id: Ia80c7e9edf7618188874e0648cb599920f49eada
Modified CPU frequency display for kSpecialType7 devices
include current frequency and max frequency to correct hardware reporting inaccuracies.

Log: Fix CPU frequency display for special device type
Task: https://pms.uniontech.com/task-view-381765.html
Change-Id: Id37a4b03a83ccb6428a1bd3edf601d905edbd2c8
Added condition to reset the driver information when its value is
"usbfs" (case-insensitive comparison) to handle invalid driver
identifiers.

Log: Filter out usbfs driver values
Bug: https://pms.uniontech.com/bug-view-333969.html
Change-Id: I4f2632c9ccef6f9df668460adda9b9078a65b932
@sourcery-ai
Copy link

sourcery-ai bot commented Dec 1, 2025

Reviewer's Guide

Aligns master with develop/eagle by adding special handling for specific board types (kSpecialType5–7), cleaning up USBFS driver reporting, tightening thread pool wait timeouts, and performing minor style/comment tweaks across device manager components.

Sequence diagram for MainJob::updateAllDevice with bounded wait timeout

sequenceDiagram
    participant MainJob
    participant ThreadPool
    participant DeviceInfoWorker

    MainJob->>ThreadPool: updateDeviceInfo()
    activate ThreadPool
    ThreadPool->>DeviceInfoWorker: start run()
    activate DeviceInfoWorker

    Note over DeviceInfoWorker: Collect device information

    DeviceInfoWorker-->>ThreadPool: run() completed
    deactivate DeviceInfoWorker

    MainJob->>ThreadPool: waitForDone(60000)
    ThreadPool-->>MainJob: return after workers done or timeout
    deactivate ThreadPool
Loading

Class diagram for Common board type handling in CPU info

classDiagram
    class Common {
        <<utility>>
        +BoardType specialComType
        +enum BoardType
    }

    class BoardType {
        <<enumeration>>
        +KLVV
        +KLVU
        +PGUV
        +kSpecialType5
        +kSpecialType6
        +kSpecialType7
        +kCustomType
    }

    class DeviceCpu {
        +QString m_Name
        +QString m_Frequency
        +QString m_MaxFrequency
        +void setCpuInfo(QMap_QString_QString mapLscpu, QMap_QString_QString mapHwinfo, int logicalNum, int coreNum)
    }

    Common --> BoardType : defines
    DeviceCpu --> Common : uses specialComType

    class QMap_QString_QString {
        <<typedef>>
    }
Loading

Class diagram for DeviceOthers USBFS driver handling

classDiagram
    class DeviceOthers {
        +QString m_Driver
        +QString m_Avail
        +QString m_MaximumPower
        +QString m_Speed
        +QString m_LogicalName
        +QString m_Modalias
        +QString m_VID_PID
        +QString m_PhysID
        +void setInfoFromLshw(QMap_QString_QString mapInfo)
        +void setInfoFromHwinfo(QMap_QString_QString mapInfo)
        +void setForcedDisplay(bool forced)
    }

    class QMap_QString_QString {
        <<typedef>>
    }

    DeviceOthers ..> QMap_QString_QString : reads attributes

    class LshwOutput {
        +QString vendor
        +QString driver
        +QString avail
        +QString maxpower
        +QString speed
        +QString logical_name
    }

    class HwinfoOutput {
        +QString Hardware_Class
        +QString Driver
        +QString Module_Alias
        +QString VID_PID
    }

    DeviceOthers ..> LshwOutput : parsed from
    DeviceOthers ..> HwinfoOutput : parsed from
Loading

Class diagram for MainJob updateAllDevice and thread pool wait timeout

classDiagram
    class MainJob {
        +bool m_firstUpdate
        +ThreadPool* m_pool
        +void updateAllDevice()
    }

    class ThreadPool {
        +void updateDeviceInfo()
        +void waitForDone(int timeoutMs)
    }

    MainJob --> ThreadPool : uses

    class DeviceInfoWorker {
        +void run()
    }

    ThreadPool o-- DeviceInfoWorker : manages workers
Loading

Class diagram for EDIDParser and ThreadExecXrandr comment-aligned fields

classDiagram
    class EDIDParser {
        +QString m_Vendor
        +QString m_Model
        +QString m_ReleaseDate
        +QString m_ScreenSize
        +QString m_MonitorName
        +QString m_EDIDHexString
        +int m_Width
        +int m_Height
        +QStringList m_ListEdid
        +QMap_QString_QString m_MapCh
    }

    class ThreadExecXrandr {
        +bool m_Gpu
        +bool m_isDXcbPlatform
        +QStringList m_monitorLst
    }

    class QMap_QString_QString {
        <<typedef>>
    }
Loading

File-Level Changes

Change Details Files
Adjust CPU frequency reporting for specific specialComType values.
  • After CPU name normalization, conditionally adjust m_Frequency from 2.189 to 2.188 for specialComType 5–7
  • Similarly normalize m_MaxFrequency from 2189 to 2188 for those special types
deepin-devicemanager/src/DeviceManager/DeviceCpu.cpp
Hide usbfs pseudo-driver so that such devices are treated as having no driver.
  • After populating attributes from lshw, clear m_Driver when it equals 'usbfs' (case-insensitive) before forced-display logic
  • After populating attributes from hwinfo, clear m_Driver when it equals 'usbfs' (case-insensitive) before fingerprint-class handling
deepin-devicemanager/src/DeviceManager/DeviceOthers.cpp
Rename PGUX enum to kSpecialType5 and keep vendor mapping behavior consistent.
  • Rename PGUX enum value in Common::SpecialType enum to kSpecialType5
  • Update switch in checkBoardVendorFlag to use kSpecialType5 while still mapping to 'PGUX'
deepin-devicemanager/src/commonfunction.h
deepin-devicemanager/src/commonfunction.cpp
Constrain device info thread pool wait time and improve minor code style consistency.
  • Change m_pool->waitForDone from infinite (-1) to a 60s timeout in MainJob::updateAllDevice
  • Reformat mapArch initializers in both client and server commonfunction headers for consistency
  • Align member declarations and comments for several helper classes (DBusAnythingInterface, EDIDParser, commontools, ThreadExecXrandr) and clarify EDIDParser’s map comment
deepin-devicemanager-server/deepin-deviceinfo/src/mainjob.cpp
deepin-devicemanager/src/commonfunction.cpp
deepin-devicemanager-server/deepin-devicecontrol/src/drivercontrol/commonfunction.h
deepin-devicemanager/src/Tool/DBusAnythingInterface.h
deepin-devicemanager/src/Tool/EDIDParser.h
deepin-devicemanager/src/Tool/commontools.h
deepin-devicemanager/src/Tool/ThreadExecXrandr.h

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@deepin-ci-robot
Copy link

[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.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@deepin-ci-robot
Copy link

deepin pr auto review

我来对这段代码的修改进行审查:

  1. 代码格式改进:
  • mapArch 的初始化格式统一化,增加了换行和缩进,提高了可读性
  • 类成员变量的对齐格式化,使代码更加整洁
  • 注释的添加和格式化,如 m_MapCh 和 m_monitorLst 的注释
  1. 逻辑修改:
  • mainjob.cpp 中将 waitForDone(-1) 改为 waitForDone(60000),这是为了避免无限等待,增加了一个60秒的超时限制。这是一个好的改动,可以防止程序卡死。

  • DeviceCpu.cpp 中增加了一个特殊类型的判断,用于修正特定硬件的频率显示。这个修改虽然解决了特定问题,但硬编码的方式可能不够优雅,建议考虑使用配置文件或其他更灵活的方式来处理。

  • DeviceOthers.cpp 中增加了对 "usbfs" 驱动的过滤,当驱动名为 "usbfs" 时将其清空。这个修改合理,因为 "usbfs" 不是一个真正的驱动程序名称。

  1. 命名规范:
  • 将 PGUX 重命名为 kSpecialType5,更好地遵循了命名规范,使用 'k' 前缀表示常量。
  1. 代码安全:
  • mainjob.cpp 中的超时设置提高了程序的健壮性
  • DeviceOthers.cpp 中的驱动过滤增加了代码的安全性

改进建议:

  1. 对于 DeviceCpu.cpp 中的频率修正,建议:
// 建议使用配置文件或常量定义来管理这些特殊值
const QMap<QString, QString> FREQUENCY_CORRECTIONS = {
    {"2.189", "2.188"},
    {"2189", "2188"}
};

if (Common::specialComType >= Common::kSpecialType5 && 
    Common::specialComType <= Common::kSpecialType7) {
    for (auto it = FREQUENCY_CORRECTIONS.begin(); it != FREQUENCY_CORRECTIONS.end(); ++it) {
        m_Frequency = m_Frequency.replace(it.key(), it.value());
        m_MaxFrequency = m_MaxFrequency.replace(it.key(), it.value());
    }
}
  1. 建议在 mainjob.cpp 中添加超时日志:
if (!m_pool->waitForDone(60000)) {
    qCWarning(appLog) << "Timeout while waiting for device update to complete";
}
  1. 对于 DeviceOthers.cpp 中的驱动过滤,建议使用常量:
static const QString USBFS_DRIVER = "usbfs";
if (m_Driver.toLower() == USBFS_DRIVER) {
    m_Driver.clear();
}

总体来说,这些修改主要关注于代码格式化和特定问题的修复,提高了代码的可读性和健壮性。建议在后续开发中继续保持良好的代码风格,并考虑使用更灵活的方式来处理特殊情况。

Copy link

@sourcery-ai sourcery-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey there - I've reviewed your changes - here's some feedback:

  • The CPU frequency adjustment for specialComType 5–7 relies on hard-coded string replacements ("2.189" → "2.188"), which is brittle; consider parsing and adjusting numeric values or basing this on detected hardware characteristics instead of literal substrings.
  • The waitForDone(60000) timeout changes behavior from infinite wait to 60 seconds without visible handling of a timeout case; it may be safer to either make this timeout configurable or explicitly handle/log the scenario where the pool does not complete within the timeout.
  • The if (m_Driver.toLower() == "usbfs") m_Driver.clear(); logic is duplicated in both setInfoFromLshw and setInfoFromHwinfo; consider extracting this into a small helper to keep the normalization logic in one place.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- The CPU frequency adjustment for specialComType 5–7 relies on hard-coded string replacements ("2.189" → "2.188"), which is brittle; consider parsing and adjusting numeric values or basing this on detected hardware characteristics instead of literal substrings.
- The `waitForDone(60000)` timeout changes behavior from infinite wait to 60 seconds without visible handling of a timeout case; it may be safer to either make this timeout configurable or explicitly handle/log the scenario where the pool does not complete within the timeout.
- The `if (m_Driver.toLower() == "usbfs") m_Driver.clear();` logic is duplicated in both `setInfoFromLshw` and `setInfoFromHwinfo`; consider extracting this into a small helper to keep the normalization logic in one place.

## Individual Comments

### Comment 1
<location> `deepin-devicemanager/src/DeviceManager/DeviceCpu.cpp:56-61` </location>
<code_context>
     m_Name.replace(QRegularExpression("x [0-9]*$"), "");
     qCDebug(appLog) << "CPU name after regex replacement: " << m_Name;

+    if (Common::specialComType == Common::kSpecialType5 ||
+        Common::specialComType == Common::kSpecialType6 ||
+        Common::specialComType == Common::kSpecialType7) {
+        m_Frequency = m_Frequency.replace("2.189", "2.188");
+        m_MaxFrequency = m_MaxFrequency.replace("2189", "2188");
</code_context>

<issue_to_address>
**suggestion (bug_risk):** Consider making the frequency replacement more robust and avoiding the redundant assignment.

In this block:

1) `QString::replace` mutates in place and returns a reference, so `m_Frequency = m_Frequency.replace(...)` / `m_MaxFrequency = ...` is redundant. A simple `m_Frequency.replace("2.189", "2.188");` is enough.

2) The replacement for `"2189"` is very broad and will also hit occurrences inside longer values (e.g. `12189`, `21890`) or in other fields if the format changes. If you only intend to adjust a specific frequency value, consider tightening the match (e.g. more constrained pattern/regex or validating the whole field before replacing) to avoid unintended substitutions.

```suggestion
    if (Common::specialComType == Common::kSpecialType5 ||
        Common::specialComType == Common::kSpecialType6 ||
        Common::specialComType == Common::kSpecialType7) {
        // Avoid broad substring replacements: only adjust when the full value matches.
        if (m_Frequency == "2.189") {
            m_Frequency = "2.188";
        }
        if (m_MaxFrequency == "2189") {
            m_MaxFrequency = "2188";
        }
    }
```
</issue_to_address>

### Comment 2
<location> `deepin-devicemanager-server/deepin-deviceinfo/src/mainjob.cpp:179` </location>
<code_context>
         qCDebug(appLog) << "Updating existing device info";
         m_pool->updateDeviceInfo();
     }
-    m_pool->waitForDone(-1);
+    m_pool->waitForDone(60000);
     PERF_PRINT_END("POINT-01");
     m_firstUpdate = false;
</code_context>

<issue_to_address>
**issue:** Introducing a 60s wait timeout may leave device updates incomplete without any handling.

Changing `waitForDone` from infinite to 60s changes behavior: if the pool is still busy after 60s, we return and still set `m_firstUpdate` to `false`, treating the update as complete. For long-running updates, this can leave device info partially updated with no signal to the caller. Consider either making the timeout configurable, or explicitly handling a timeout (if the pool API supports it), e.g. by logging it, not clearing `m_firstUpdate`, retrying, or otherwise surfacing an error state.
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment on lines +56 to +61
if (Common::specialComType == Common::kSpecialType5 ||
Common::specialComType == Common::kSpecialType6 ||
Common::specialComType == Common::kSpecialType7) {
m_Frequency = m_Frequency.replace("2.189", "2.188");
m_MaxFrequency = m_MaxFrequency.replace("2189", "2188");
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion (bug_risk): Consider making the frequency replacement more robust and avoiding the redundant assignment.

In this block:

  1. QString::replace mutates in place and returns a reference, so m_Frequency = m_Frequency.replace(...) / m_MaxFrequency = ... is redundant. A simple m_Frequency.replace("2.189", "2.188"); is enough.

  2. The replacement for "2189" is very broad and will also hit occurrences inside longer values (e.g. 12189, 21890) or in other fields if the format changes. If you only intend to adjust a specific frequency value, consider tightening the match (e.g. more constrained pattern/regex or validating the whole field before replacing) to avoid unintended substitutions.

Suggested change
if (Common::specialComType == Common::kSpecialType5 ||
Common::specialComType == Common::kSpecialType6 ||
Common::specialComType == Common::kSpecialType7) {
m_Frequency = m_Frequency.replace("2.189", "2.188");
m_MaxFrequency = m_MaxFrequency.replace("2189", "2188");
}
if (Common::specialComType == Common::kSpecialType5 ||
Common::specialComType == Common::kSpecialType6 ||
Common::specialComType == Common::kSpecialType7) {
// Avoid broad substring replacements: only adjust when the full value matches.
if (m_Frequency == "2.189") {
m_Frequency = "2.188";
}
if (m_MaxFrequency == "2189") {
m_MaxFrequency = "2188";
}
}

qCDebug(appLog) << "Updating existing device info";
m_pool->updateDeviceInfo();
}
m_pool->waitForDone(-1);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue: Introducing a 60s wait timeout may leave device updates incomplete without any handling.

Changing waitForDone from infinite to 60s changes behavior: if the pool is still busy after 60s, we return and still set m_firstUpdate to false, treating the update as complete. For long-running updates, this can leave device info partially updated with no signal to the caller. Consider either making the timeout configurable, or explicitly handling a timeout (if the pool API supports it), e.g. by logging it, not clearing m_firstUpdate, retrying, or otherwise surfacing an error state.

@add-uos
Copy link
Contributor Author

add-uos commented Dec 1, 2025

/forcemerge

@deepin-bot
Copy link
Contributor

deepin-bot bot commented Dec 1, 2025

This pr force merged! (status: unstable)

@deepin-bot deepin-bot bot merged commit 4cc5684 into linuxdeepin:master Dec 1, 2025
16 of 18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants