Skip to content

fix: correct initial color temperature value when enabled#1079

Open
fly602 wants to merge 1 commit intolinuxdeepin:masterfrom
fly602:fix-355459
Open

fix: correct initial color temperature value when enabled#1079
fly602 wants to merge 1 commit intolinuxdeepin:masterfrom
fly602:fix-355459

Conversation

@fly602
Copy link
Copy Markdown
Contributor

@fly602 fly602 commented Apr 2, 2026

The issue was that when color temperature was enabled, the initial value was incorrect due to inconsistent default temperature values across different modules. The constant defaultTemperature was removed and replaced with consistent usage of _dsDefaultTemperatureManual. The manager's ColorTemperatureManual property is now properly initialized by calling getDefaultTemperatureManual() method which sets it to the correct system default value.

Previously, the defaultTemperature constant (6500) was used in some places while _dsDefaultTemperatureManual was used in others, causing inconsistency. The fix ensures that all modules use the same default value obtained from the system configuration.

Log: Fixed incorrect initial color temperature value when enabling color temperature feature

Influence:

  1. Test enabling color temperature feature and verify the initial value is correct
  2. Test switching between different color temperature modes (Auto, Manual, Custom)
  3. Verify that manual color temperature adjustments work properly
  4. Test system behavior after reboot with color temperature enabled
  5. Verify consistency of color temperature values across different display configurations

fix: 修复开启色温时初始值不正确的问题

问题在于启用色温功能时,由于不同模块间默认温度值不一致,
导致初始值不正确。移除了 defaultTemperature 常量,统一使用
_dsDefaultTemperatureManual。管理器的 ColorTemperatureManual 属性现在通 过调用 getDefaultTemperatureManual() 方法正确初始化为系统默认值。

之前,部分代码使用 defaultTemperature 常量(6500),而其他部分使用
_dsDefaultTemperatureManual,导致不一致。修复后确保所有模块使用从系统配
置获取的相同默认值。

Log: 修复开启色温功能时初始值不正确的问题

Influence:

  1. 测试启用色温功能,验证初始值是否正确
  2. 测试在不同色温模式(自动、手动、自定义)间切换
  3. 验证手动调节色温功能正常工作
  4. 测试重启系统后色温功能的保持情况
  5. 验证不同显示配置下色温值的一致性

PMS: BUG-355459
Change-Id: If2bd2b716a9a73e79dfe5634757e3f757988a4bc

Summary by Sourcery

Unify color temperature defaults to use the system-provided manual temperature value, ensuring consistent initialization and behavior when the color temperature feature is enabled.

Bug Fixes:

  • Fix incorrect initial manual color temperature value when enabling the color temperature feature by aligning all modules to the system default.

Enhancements:

  • Initialize the manager's manual color temperature from the system configuration helper instead of a hardcoded default.
  • Update color temperature value selection logic to consistently fall back to the system default manual temperature rather than a fixed constant.

Chores:

  • Update SPDX copyright headers to extend coverage years to 2026.

The issue was that when color temperature was enabled, the initial
value was incorrect due to inconsistent default temperature values
across different modules. The constant defaultTemperature was removed
and replaced with consistent usage of _dsDefaultTemperatureManual. The
manager's ColorTemperatureManual property is now properly initialized
by calling getDefaultTemperatureManual() method which sets it to the
correct system default value.

Previously, the defaultTemperature constant (6500) was used in some
places while _dsDefaultTemperatureManual was used in others, causing
inconsistency. The fix ensures that all modules use the same default
value obtained from the system configuration.

Log: Fixed incorrect initial color temperature value when enabling color
temperature feature

Influence:
1. Test enabling color temperature feature and verify the initial value
is correct
2. Test switching between different color temperature modes (Auto,
Manual, Custom)
3. Verify that manual color temperature adjustments work properly
4. Test system behavior after reboot with color temperature enabled
5. Verify consistency of color temperature values across different
display configurations

fix: 修复开启色温时初始值不正确的问题

问题在于启用色温功能时,由于不同模块间默认温度值不一致,
导致初始值不正确。移除了 defaultTemperature 常量,统一使用
_dsDefaultTemperatureManual。管理器的 ColorTemperatureManual 属性现在通
过调用 getDefaultTemperatureManual() 方法正确初始化为系统默认值。

之前,部分代码使用 defaultTemperature 常量(6500),而其他部分使用
_dsDefaultTemperatureManual,导致不一致。修复后确保所有模块使用从系统配
置获取的相同默认值。

Log: 修复开启色温功能时初始值不正确的问题

Influence:
1. 测试启用色温功能,验证初始值是否正确
2. 测试在不同色温模式(自动、手动、自定义)间切换
3. 验证手动调节色温功能正常工作
4. 测试重启系统后色温功能的保持情况
5. 验证不同显示配置下色温值的一致性

PMS: BUG-355459
Change-Id: If2bd2b716a9a73e79dfe5634757e3f757988a4bc
@deepin-ci-robot
Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: fly602

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

@sourcery-ai
Copy link
Copy Markdown

sourcery-ai bot commented Apr 2, 2026

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Aligns the default manual color temperature handling across display modules by removing the hard‑coded constant, consistently using the system-derived _dsDefaultTemperatureManual value, and initializing the manager’s ColorTemperatureManual from getDefaultTemperatureManual().

Sequence diagram for color temperature manual initialization flow

sequenceDiagram
    actor User
    participant DisplayService
    participant Manager
    participant SystemConfig

    User->>DisplayService: enableColorTemperature()
    DisplayService->>Manager: newManager(service)
    activate Manager
    Manager->>SystemConfig: getDefaultTemperatureManual()
    activate SystemConfig
    SystemConfig-->>Manager: _dsDefaultTemperatureManual
    deactivate SystemConfig
    Manager->>Manager: set ColorTemperatureManual = _dsDefaultTemperatureManual
    Manager-->>DisplayService: initialized Manager instance
    deactivate Manager

    User->>DisplayService: requestCurrentColorTemperature()
    DisplayService->>Manager: getColorTemperatureValue()
    Manager-->>DisplayService: temperature based on consistent _dsDefaultTemperatureManual
    DisplayService-->>User: show current color temperature
Loading

Updated class diagram for color temperature manager and config

classDiagram
    class Manager {
        +int ColorTemperatureManual
        +int ColorTemperatureMode
        +getColorTemperatureValue() int
        +getDefaultTemperatureManual()
    }

    class UserMonitorModeConfig {
        +int ColorTemperatureMode
        +int ColorTemperatureManual
        +int ColorTemperatureModeOn
        +fix()
        +clone() UserMonitorModeConfig
    }

    class RedshiftRunner {
        +getValue() int
    }

    class SystemConfig {
        +int _dsDefaultTemperatureManual
        +getDefaultTemperatureManual() int
    }

    Manager --> RedshiftRunner : uses
    Manager --> SystemConfig : reads _dsDefaultTemperatureManual
    UserMonitorModeConfig --> SystemConfig : uses _dsDefaultTemperatureManual for defaults
Loading

File-Level Changes

Change Details Files
Unify color temperature default handling to use the system-derived manual temperature value instead of a hard-coded constant.
  • Removed the defaultTemperature constant and replaced its usages with defaultTemperatureManual or _dsDefaultTemperatureManual where appropriate
  • Updated getColorTemperatureValue logic to treat the system manual default as the reference value for Auto and Custom modes and to return the system default when no mode matches
  • Adjusted UserMonitorModeConfig normalization and default-construction to use _dsDefaultTemperatureManual for ColorTemperatureManual
  • Initialized Manager.ColorTemperatureManual inside getDefaultTemperatureManual so it is populated from the system configuration instead of a compile-time default
  • Updated SPDX copyright headers to reflect the 2022–2026 range
display1/color_temp.go
display1/displayconf.go
display1/manager.go

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

Copy link
Copy Markdown

@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 - I've found 1 issue, and left some high level feedback:

  • Now that m.ColorTemperatureManual is only initialized via getDefaultTemperatureManual(), double-check that this method is always invoked before any consumer reads ColorTemperatureManual (including during manager construction and config load) to avoid transient zero/incorrect values.
  • Directly using the global _dsDefaultTemperatureManual inside UserMonitorModeConfig.fix() and getDefaultUserMonitorModeConfig() couples config logic to global state; consider passing the default value in or centralizing default resolution in one place to make initialization order and behavior easier to reason about.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- Now that `m.ColorTemperatureManual` is only initialized via `getDefaultTemperatureManual()`, double-check that this method is always invoked before any consumer reads `ColorTemperatureManual` (including during manager construction and config load) to avoid transient zero/incorrect values.
- Directly using the global `_dsDefaultTemperatureManual` inside `UserMonitorModeConfig.fix()` and `getDefaultUserMonitorModeConfig()` couples config logic to global state; consider passing the default value in or centralizing default resolution in one place to make initialization order and behavior easier to reason about.

## Individual Comments

### Comment 1
<location path="display1/color_temp.go" line_range="398-400" />
<code_context>
 			value = int(manual)
 		}
 		return value
 	case ColorTemperatureModeCustom:
-		value := defaultTemperature
+		value := defaultTemperatureManual
 		if m.customColorTempFlag {
 			value = int(manual)
 		}
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Mixing `defaultTemperatureManual` and `_dsDefaultTemperatureManual` may lead to inconsistent defaults

Here, the `ColorTemperatureModeCustom` branch still bases its value on `defaultTemperatureManual`, while the final fallback now uses `int(_dsDefaultTemperatureManual)`. Since `_dsDefaultTemperatureManual` is loaded dynamically in `getDefaultTemperatureManual`, this can yield different defaults depending on the path taken. Please standardize on one source (dynamic or constant) within `getColorTemperatureValue` so the manual temperature default is consistent across all branches.

Suggested implementation:

```golang
		// 日落时,返回手动设置的色温(from v20)
		if value != int(_dsDefaultTemperatureManual) {

```

```golang
	case ColorTemperatureModeCustom:
		value := int(_dsDefaultTemperatureManual)

```
</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 398 to 400
case ColorTemperatureModeCustom:
value := defaultTemperature
value := defaultTemperatureManual
if m.customColorTempFlag {
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

suggestion (bug_risk): Mixing defaultTemperatureManual and _dsDefaultTemperatureManual may lead to inconsistent defaults

Here, the ColorTemperatureModeCustom branch still bases its value on defaultTemperatureManual, while the final fallback now uses int(_dsDefaultTemperatureManual). Since _dsDefaultTemperatureManual is loaded dynamically in getDefaultTemperatureManual, this can yield different defaults depending on the path taken. Please standardize on one source (dynamic or constant) within getColorTemperatureValue so the manual temperature default is consistent across all branches.

Suggested implementation:

		// 日落时,返回手动设置的色温(from v20)
		if value != int(_dsDefaultTemperatureManual) {
	case ColorTemperatureModeCustom:
		value := int(_dsDefaultTemperatureManual)

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.

2 participants