feat(shortcut): migrate shortcut handling to dde-services

[yixinshark]

Summary

• Migrate shortcut ownership from dde-daemon to dde-services by disabling the legacy session keybinding module and removing its D-Bus activation file.
• Remove the legacy configurable touchpad gesture API while retaining touchscreen gesture handling.
• Make gesture input-loop lifecycle and simulated touchscreen right-button cleanup deterministic.

Test plan

• go test ./bin/dde-session-daemon ./gesture1 ./system/gesture1
• Verify shortcuts are handled by dde-services on X11 and Treeland.
• Verify touchscreen edge gestures and long-press right-click behavior.
• Verify restarting gesture services leaves no stuck input state.

Pms: TASK-393199

[sourcery-ai]

Sorry @yixinshark, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[deepin-ci-robot]

deepin pr auto review

★ 总体评分：85分

■ 【总体评价】

代码重构了触摸右键事件处理逻辑并加固了C端事件循环的并发安全，整体质量良好。
逻辑正确且修复了资源泄漏问题，但存在持锁睡眠的性能瑕疵导致扣分。

■ 【详细分析】

• 1.语法逻辑（基本正确）✓

gesture1/manager.go 中的 handleTouchRightButton 和 releaseTouchRightButton 通过 touchRightButtonMu 互斥锁保护状态，逻辑正确。system/gesture1/core.c 中的 start_loop 引入了管道唤醒机制和定时器回调生命周期管理，修复了无法安全退出的问题。
潜在问题：releaseTouchRightButtonLocked 在持有锁的情况下进行重试和 time.Sleep，如果底层 xdotool 响应缓慢，会导致锁长时间被占用。
建议：将重试逻辑移出临界区，或者在睡眠期间释放锁，避免阻塞其他并发请求。

• 2.代码质量（优秀）✓

移除了大量未使用的 D-Bus 导出方法和依赖，精简了模块结构。system/gesture1/core.c 中引入了 tap_generation 机制来防止过期定时器回调的影响，设计合理。
潜在问题：无
建议：无

• 3.代码性能（存在性能问题）✕

gesture1/manager.go 的 releaseTouchRightButtonLocked 函数在最坏情况下会持有 touchRightButtonMu 锁长达 150ms（3次重试，每次间隔50ms），这会阻塞 handleTouchRightButton 等其他需要获取该锁的操作。
潜在问题：持锁睡眠导致并发性能下降。
建议：在重试循环中，每次调用 doXdotoolsMouseUp 前获取锁，调用后释放锁，然后再进行 time.Sleep。

• 4.代码安全（存在0个安全漏洞）✓

漏洞对比统计：新增漏洞 0 个，减少漏洞 0 个，持平 0 个
代码未引入外部不可信输入参与命令执行或内存操作，exec.Command 使用了硬编码参数，无注入风险。C 代码中内存分配和释放配对正确，无缓冲区溢出风险。

• 建议：无需额外修复。

■ 【改进建议代码示例】

// gesture1/manager.go
func (m *Manager) releaseTouchRightButtonLocked() error {
	if !m.touchRightButtonDown {
		return nil
	}
	var lastErr error
	for attempt := 0; attempt < touchRightButtonReleaseAttempts; attempt++ {
		// 释放锁执行可能阻塞的操作
		m.touchRightButtonMu.Unlock()
		err := m.doXdotoolsMouseUp()
		m.touchRightButtonMu.Lock()
		
		if err == nil {
			m.touchRightButtonDown = false
			return nil
		} else {
			lastErr = err
		}
		if attempt+1 < touchRightButtonReleaseAttempts {
			// 释放锁后再睡眠
			m.touchRightButtonMu.Unlock()
			time.Sleep(touchRightButtonReleaseInterval)
			m.touchRightButtonMu.Lock()
		}
	}
	return fmt.Errorf("mouseup failed after %d attempts: %w", touchRightButtonReleaseAttempts, lastErr)
}

[yixinshark]

/retest

[yixinshark]

deepin pr auto review

★ 总体评分：85分

■ 【总体评价】

代码重构了触摸右键事件处理逻辑并加固了C端事件循环的并发安全，整体质量良好。
逻辑正确且修复了资源泄漏问题，但存在持锁睡眠的性能瑕疵导致扣分。

■ 【详细分析】

• 1.语法逻辑（基本正确）✓

gesture1/manager.go 中的 handleTouchRightButton 和 releaseTouchRightButton 通过 touchRightButtonMu 互斥锁保护状态，逻辑正确。system/gesture1/core.c 中的 start_loop 引入了管道唤醒机制和定时器回调生命周期管理，修复了无法安全退出的问题。
潜在问题：releaseTouchRightButtonLocked 在持有锁的情况下进行重试和 time.Sleep，如果底层 xdotool 响应缓慢，会导致锁长时间被占用。
建议：将重试逻辑移出临界区，或者在睡眠期间释放锁，避免阻塞其他并发请求。

• 2.代码质量（优秀）✓

移除了大量未使用的 D-Bus 导出方法和依赖，精简了模块结构。system/gesture1/core.c 中引入了 tap_generation 机制来防止过期定时器回调的影响，设计合理。
潜在问题：无
建议：无

• 3.代码性能（存在性能问题）✕

gesture1/manager.go 的 releaseTouchRightButtonLocked 函数在最坏情况下会持有 touchRightButtonMu 锁长达 150ms（3次重试，每次间隔50ms），这会阻塞 handleTouchRightButton 等其他需要获取该锁的操作。
潜在问题：持锁睡眠导致并发性能下降。
建议：在重试循环中，每次调用 doXdotoolsMouseUp 前获取锁，调用后释放锁，然后再进行 time.Sleep。

• 4.代码安全（存在0个安全漏洞）✓

漏洞对比统计：新增漏洞 0 个，减少漏洞 0 个，持平 0 个
代码未引入外部不可信输入参与命令执行或内存操作，exec.Command 使用了硬编码参数，无注入风险。C 代码中内存分配和释放配对正确，无缓冲区溢出风险。

• 建议：无需额外修复。

■ 【改进建议代码示例】

// gesture1/manager.go
func (m *Manager) releaseTouchRightButtonLocked() error {
	if !m.touchRightButtonDown {
		return nil
	}
	var lastErr error
	for attempt := 0; attempt < touchRightButtonReleaseAttempts; attempt++ {
		// 释放锁执行可能阻塞的操作
		m.touchRightButtonMu.Unlock()
		err := m.doXdotoolsMouseUp()
		m.touchRightButtonMu.Lock()
		
		if err == nil {
			m.touchRightButtonDown = false
			return nil
		} else {
			lastErr = err
		}
		if attempt+1 < touchRightButtonReleaseAttempts {
			// 释放锁后再睡眠
			m.touchRightButtonMu.Unlock()
			time.Sleep(touchRightButtonReleaseInterval)
			m.touchRightButtonMu.Lock()
		}
	}
	return fmt.Errorf("mouseup failed after %d attempts: %w", touchRightButtonReleaseAttempts, lastErr)
}

这条应判为“影响评估不成立”，不建议按 AI 的方案修改。锁内确实有 Sleep，但性能问题被明显夸大了。

原因：

• 3 次尝试之间实际只有 2 次休眠，即 2 × 50ms = 100ms，不是 150ms。dde-daemon/gesture1/manager.go:472
• 只有 xdotool mouseup 失败时才会休眠；正常路径第一次成功便立即返回。
• 这是专用于触摸右键状态的细粒度锁，只影响 mousedown/mouseup/stop，不会阻塞其他手势处理。
• Gesture D-Bus 信号本身由单个 SignalLoop goroutine 顺序处理。即使休眠期间释放 mutex，后续 handleTouchRightButton 也无法在同一信号循环中执行，因此 AI 建议并不能解决它描述的阻塞。
• 当前锁保证 mouseup 重试、touchRightButtonDown 更新和新的 mousedown 不会交错。简单地在重试间释放锁会允许其他释放流程插入，需要额外的 releasing 状态才能保持状态机严谨。

真正值得注意的是：exec.Command("xdotool", ...) 没有超时，所以理论阻塞时间并非 150ms，而可能更长。但这是可靠性加固项，不是当前报告所说的锁竞争性能问题，也不必阻塞该 PR。

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: 18202781743, yixinshark

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

[yixinshark]

/forcemerge