Fix sensor

[fly602]

No description provided.

[sourcery-ai]

Sorry @fly602, your pull request is larger than the review limit of 150000 diff characters

[robertkill]

Code Review — 自动亮度功能

整体架构设计不错，卡尔曼滤波和亮度曲线实现质量较高。但有3个Critical问题需要修。

🔴 Critical（merge前必须修）

C1 display1/auto_brightness.go L1109/1205/1213 — 不安全类型断言会 PANIC

config.BrightnessChangeThreshold = val.Value().(float64)  // D-Bus int64时crash
config.KalmanProcessNoise = val.Value().(float64)          // 同上
config.KalmanMeasurementNoise = val.Value().(float64)      // 同上

同文件其他字段都用了 type switch（如L1078-1086），这三处漏了，DSettings返回int64时直接panic。建议统一用type switch处理。

C2 kalman_filter.go — 并发数据竞争
补偿定时器（150ms）调 GetEstimate() 只持有 RLock，传感器回调调 Update() 修改 xEst/PEst。两者并发 = data race。建议给 KalmanFilter1D 加独立 mutex，或确保 GetEstimate 也用写锁。

C3 auto_brightness.go Stop/Start 竞态
Stop() 中 stopCompensationTimer() 会 Unlock→Wait→Relock，窗口期内 Start() 可创建新 ticker。Stop() 之后设 running=false 会覆盖新状态，新 ticker 变孤儿泄漏。建议加 atomic stopping 标志或重构锁逻辑。

⚠️ Warnings

W1 brightness_transition.go L299 — task.ctx.(chan struct{}) 不安全断言，建议存为强类型或改用 context.Context

W2 runTransition goroutine 无 WaitGroup 追踪，Stop() 后可能仍在运行

W3 sessionActive 字段跨 goroutine 读写无同步保护

W4 getConfig 中类型断言风格不一致（部分 type switch，部分直接断言）

💡 Suggestions

• 多处 "faild" 拼写错误 → "failed"
• 补偿 ticker Info 日志 150ms/次太频繁，建议改 Debug
• 1024.0 硬编码 lux 上限，室外场景会超，建议可配置或对数映射
• claimLightWithRetry 在 auto_brightness.go 和 sensor_proxy.go 重复实现
• TransitionExecutor 建议用 context.Context 替代 chan struct{}
• saveConfig 非原子写入，crash会半写

✅ 亮点

• RWMutex 读路径优化合理
• 手动覆盖机制防止和用户操作冲突
• 卡尔曼滤波数学实现正确
• 亮度曲线插值边界处理完善
• 初始化逐步降级策略（config失败→默认，sensor失败→不支持）

[robertkill]

Critical 问题具体位置

C1 display1/auto_brightness.go:1109 display1/auto_brightness.go:1205 display1/auto_brightness.go:1213

// 这三处会 panic，DSettings integer 返回 int64：
config.BrightnessChangeThreshold = val.Value().(float64)   // L1109
config.KalmanProcessNoise = val.Value().(float64)          // L1205
config.KalmanMeasurementNoise = val.Value().(float64)      // L1213
// 应改用同文件 L1078 的 type switch 写法

C2 display1/brightness/kalman_filter.go — GetEstimate() 无锁保护

• L728 abm.kalmanFilter.GetEstimate() 在补偿定时器中被调用（只持有 RLock）
• L665 abm.kalmanFilter.Update() 在传感器回调中修改 xEst/PEst（持有写锁）
• RLock 和 Lock 并发 = data race，需给 KalmanFilter1D 加独立 mutex

C3 display1/auto_brightness.go:831 — stopCompensationTimer() Unlock 窗口

• Stop() → stopCompensationTimer() → Unlock→Wait→Relock（L831-833）
• 窗口期内 Start() 可创建新 ticker，Stop() 设 running=false 覆盖新状态

[robertkill]

Code Review Summary

Verdict: Changes Requested (4 Critical, 7 Warnings, 7 Suggestions)

---

🔴 Critical

C1. saveConfig() 读取 abm.config 未持锁 — 数据竞争
display1/auto_brightness.go — saveConfig() 直接读取 abm.config.Enabled、abm.config.Sensitivity 等字段，没有任何锁保护。与 OnConfigChanged()（持锁写 config）和 OnManualBrightnessChange()（持锁修改 config.Enabled）存在竞态。
建议： 在方法开头持锁快照 config，释放锁后再序列化。

C2. stopCompensationTimer() 的 Unlock→Wait→Lock 模式极其脆弱
display1/auto_brightness.go — 该方法要求调用者已持 abm.mutex，然后内部 Unlock→Wait→Lock。如果未来有人在 defer abm.mutex.Unlock() 的上下文中调用，会 double-unlock 导致 panic。
建议： 使用独立的 compensationMu，或重构使补偿 goroutine 不需要 abm.mutex。

C3. Kalman Filter 双锁潜在死锁风险
display1/brightness/kalman_filter.go — AdaptiveKalmanFilter.Update() 持有 akf.mu，内部调用 akf.SetMeasurementNoise() 又去获取 kf.mu。当前调用路径不会死锁，但锁顺序是隐式的，未来维护者很容易引入死锁。
建议： 添加不加锁的内部方法 setMeasurementNoiseLocked()，在已持 akf.mu 时调用，并明确文档化锁顺序。

C4. startServiceWatching() 中 SignalLoop 泄漏
display1/sensor_proxy.go — sigLoop 作为局部变量创建并 Start()，但从未存储也从未 Stop()。每次 Connect() 调用都会泄漏一个永久运行的 goroutine。
建议： 将 sigLoop 存到结构体上，在 Disconnect() 中调用 sigLoop.Stop()。

---

🟡 Warnings

W1. getBacklightCurvePercent() 读取曲线状态未持锁
display1/brightness/curve.go — 读取 cm.curveType、cm.flmCurveFunc 等字段无锁保护，与写入端存在数据竞争。

W2. getCurveValue() 同样未持锁读取
display1/brightness/curve.go — 与 W1 同类问题。

W3. go callback() 在 sensor_proxy.go 中无生命周期同步
display1/sensor_proxy.go:369,388 — 回调在新 goroutine 中执行，如果 Cleanup() 后回调仍触发，可能访问已释放资源。

W4. calculateTargetBrightness() 死代码
display1/auto_brightness.go — if br >= 0 { if br < 0.0 { ... } } 中 br < 0.0 分支永远不可达。

W5. ensureSensorClaimed() TOCTOU 竞态
display1/auto_brightness.go — 先检查 IsClaimed() 再 ClaimLight()，两步之间状态可能变化。

W6. transitionTask.ctx 类型为 interface{} 缺乏类型安全
display1/brightness/brightness_transition.go:78 — 实际用作 chan struct{}，多处需类型断言，应直接定义为具体类型。

W7. 硬编码最小亮度 10%
display1/auto_brightness.go:870,892 — 0.1 应提取为命名常量或纳入配置。

---

💡 Suggestions

1. 使用 context.Context 替代手动 compensationStopCh 做取消，更符合 Go 惯例
2. ExponentialMovingAverage 和 MovingAverage 没有并发保护且当前未使用，建议删除
3. claimLightWithRetry() 最多阻塞 6 秒（3次×2秒），考虑用 context + timeout
4. fallback 线性映射 adjustedLevel / 1024.0 中 1024 是 magic number，应可配置或从传感器读取
5. 暴露 D-Bus 方法触发立即亮度调整，方便调试
6. setBrightness() 访问 abm.manager 未持锁，应至少做 nil 检查
7. OnManualBrightnessChange() 异步 go saveConfig() 可能读到被其他 goroutine 修改的 config

---

✅ Looks Good

• 补偿定时器的注释清晰解释了 Unlock/Wait/Lock 的原因
• Stop/Start 窗口期的 atomic flag 设计正确
• 模块分层清晰：SensorProxyClient → AutoBrightnessManager → brightness 包
• Kalman 滤波数学公式正确（标准 predict-update cycle）
• 渐变效果的 cancelTask 模式正确处理了新目标中断旧任务
• 配置校验合理，异常时安全回退到默认值
• 曲线插值正确处理了边界情况

---

Reviewed by Hermes Agent

[deepin-ci-robot]

deepin pr auto review

本次代码审查针对自动亮度调节、亮度渐变以及背光曲线等功能的提交进行了详细分析。整体来看，代码架构清晰，模块划分合理，状态机和锁机制设计较为完善。但在并发控制、代码质量、性能优化和安全性方面仍有一些需要改进的地方。

以下是详细的审查意见：

1. 语法与逻辑

1.1 潜在的死锁风险

• 文件: display1/auto_brightness.go
• 问题: stopCompensationTimer() 方法的注释标明“调用者必须持有 abm.mutex 锁”，而在该方法内部调用了 abm.compensationWg.Wait()。然而，compensationTicker 的 goroutine 内部调用了 abm.compensationTick()，而 compensationTick() 的第一行就是 abm.mutex.Lock()。
  当持有 abm.mutex 的 goroutine 调用 stopCompensationTimer() 并执行 Wait() 等待时，goroutine 可能正阻塞在 abm.mutex.Lock() 上，从而导致死锁。
• 建议: 不要在持有 abm.mutex 的情况下调用 compensationWg.Wait()。可以先将 ticker 和 channel 停止并置空，释放锁后再执行 Wait()，或者重构锁的粒度。

1.2 竞态条件

• 文件: display1/auto_brightness.go
• 问题: OnManualBrightnessChange() 中，在释放锁后启动了异步 goroutine：go func() { ... abm.saveConfig() ... abm.Stop() ... }()。Stop() 方法内部会获取锁并修改状态。如果在此期间有其他并发请求（如 SetEnabled），可能导致状态混乱。另外，abm.config.Enabled = false 是在锁内修改的，但 saveConfig() 是在锁外异步执行的，这期间如果配置被再次修改，可能会保存错误的中间状态。
• 建议: 将 saveConfig 和状态更新放在同一个受保护的逻辑流中，或者通过 channel 串行化状态变更事件。异步保存配置时，应在加锁期间拷贝所需的配置快照。

1.3 逻辑缺陷

• 文件: display1/brightness/curve.go
• 问题: generateCustomCurveFunc 返回的闭包中，使用了 cm.mu.RLock()。因为 cm 是全局变量 _curveManager 的指针，闭包被长期持有并调用，这会导致外部在调用 getCurveValue（也持有锁）时，如果触发到 limitedCurveFunc，由于同协程重复加读锁（RLock 重入），虽然 RWMutex 允许多个读锁，但如果此时有写锁介入，可能会造成饥饿或死锁。
• 建议: 闭包内部不需要再动态读取 cm.maxBrightnessUnlimited，可以在创建闭包时（即 generateCustomCurveFunc 被调用时）将此值捕获为局部变量，或者将 unlimited 状态作为参数传入。

2. 代码质量

2.1 大量重复代码

• 文件: display1/auto_brightness.go 中的 getConfig 方法
• 问题: 读取 DSettings 配置的代码极度冗余，每个配置项都有近乎相同的 switch v := val.Value().(type) 和错误处理逻辑，导致方法长达 200 多行。
• 建议: 抽取通用的泛型配置读取函数或辅助方法，例如：

  func getFloat64Config(mgr configManager.Manager, key string, defaultVal float64) float64 {
      if val, err := mgr.Value(0, key); err == nil {
          switch v := val.Value().(type) {
          case float64: return v
          case int64: return float64(v)
          }
      }
      return defaultVal
  }

2.2 未使用的变量与导入

• 文件: display1/brightness/brightness.go
• 问题: 移除了 multierr 包的引用，但在 _setBacklight 中仍然使用 fmt.Printf 输出调试信息，且 SetBacklight 函数忽略了部分控制器的错误（只记录日志继续循环），这在库级别代码中不够严谨。
• 建议: 将 fmt.Printf 替换为 logger.Debugf。对于 SetBacklight，如果任何一个控制器设置失败，应考虑返回组合错误或明确说明为何忽略错误。

2.3 魔法数字

• 文件: display1/auto_brightness.go
• 问题: calculateTargetBrightness 中 maxSensorLux = 1024.0，但在计算时使用 adjustedLevel / maxSensorLux，如果传感器返回的值超过 1024，计算结果会被截断到 1.0，这虽然安全，但缺乏解释。
• 建议: 增加注释说明为何最大勒克斯值设定为 1024，或者将其提取为可配置项。

3. 代码性能

3.1 高频定时器与锁争用

• 文件: display1/auto_brightness.go
• 问题: compensationTicker 的间隔为 150ms，每次触发都会尝试获取 mutex 锁。这在系统负载高时可能引起频繁的锁争用，影响其他 UI 线程的 D-Bus 调用。
• 建议: 考虑将补偿定时器的间隔适当延长（如 500ms 或 1s），或者采用无锁队列/Channel 异步处理传感器数据，减少锁的持有时间。

3.2 字符串替换的性能开销

• 文件: display1/brightness/curve.go
• 问题: parseDefaultBrightnessCurve 和 parseCustomBrightnessCurves 中使用了 strings.ReplaceAll(jsonStr, "\\", "") 来移除反斜杠。这种做法不仅破坏了 JSON 中合法的转义字符（如字符串内部包含引号的情况），而且在 JSON 较大时产生不必要的内存分配。
• 建议: 直接使用标准库的 json.Unmarshal，它能完美处理转义。如果是为了修复格式错误的 JSON，应在数据源头修复，而不是在运行时暴力替换。

4. 代码安全

4.1 资源泄漏

• 文件: display1/sensor_proxy.go
• 问题: startServiceWatching 中，每次调用都会新建一个 dbusutil.NewSignalLoop 并启动：sigLoop.Start()。但在 Disconnect 中虽然调用了 sigLoop.Stop()，如果 Connect 被多次调用（例如服务重启触发重连），可能导致旧的 serviceSigLoop 未被正确停止和回收，造成 Goroutine 泄漏。
• 建议: 确保 serviceSigLoop 是单例或复用的，在创建新的之前，必须确保旧的已经完全停止并回收。

4.2 D-Bus 方法权限与输入校验

• 文件: display1/manager_ifc.go
• 问题: SetAutoBrightnessEnabled 方法直接暴露在 Session D-Bus 上，任何同会话的应用都可以调用。虽然这是预期行为，但配置的保存（saveConfig）涉及全局 DConfig 写入，如果缺乏速率限制，恶意应用可以高频切换状态导致系统抖动。
• 建议: 在 SetAutoBrightnessEnabled 入口处增加防抖逻辑或频率限制。

4.3 JSON 解析安全性

• 文件: display1/brightness/curve.go
• 问题: SetCustomBrightnessCurves 和 SetDefaultBrightnessCurve 接受外部传入的 JSON 字符串并解析。虽然目前是从 DConfig 读取，但如果 DConfig 被篡改包含畸形超长 JSON，可能导致解析时内存暴涨。
• 建议: 对传入的 JSON 字符串长度进行上限检查，或在解析时使用 json.Decoder 并设置 DisallowUnknownFields 以防止意外注入。

总结建议

1. 优先修复死锁隐患：stopCompensationTimer 中持锁调用 WaitGroup.Wait() 是极其危险的，必须重构。
2. 重构冗余代码：getConfig 中的配置读取逻辑必须抽象化，否则后续维护成本极高。
3. 优化锁粒度：减少高频定时器对主锁的依赖，降低 D-Bus 通信延迟。
4. 清理调试代码：移除 fmt.Printf，统一使用日志库。

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: fly602, mhduiy, robertkill

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

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