Planet deepin | 简体中文

deepin-ports SIG 周报 (2026-06-05)

deepin-ports SIG — Fri, 05 Jun 2026 00:00:00 +0000

本周进展

deepin-ports 维护

已推进新版 aic8800 合入仓库，以便 7.0 以上内核能够使用。
已将 SC8280XP 相关固件推送进 linux-firmware。
将 q6a 镜像重命名为 qcom，适配 Radxa 旗下所有 qcom 开发板。
为 deepin-ports-image 增加了 next 仓库 profile。
发布了一版 qcom 镜像，基于 deepin 25.1.1。

其它

参加了 Radxa & 高通开发者大会，在会上作 deepin on arm64 (qcom) 设备展示。
- 撰写并发布了公众号新闻：https://mp.weixin.qq.com/s/kGKetWMrAVMZUFwlCh4fiA

下周规划

RVA23 仓库部分已推迟

争取 RVA23 RFC 能够尽快获得通过，以便正式确定技术规范。
进行一些基础库的重构，以便利用 RVA23 提升性能。
准备在 deepin-ports-image 中增加单独的 RVA23 仓库选项。
继续升级 rust 工具链至 1.88+。
升级 mesa 26.1.0。

RISC-V 转译应用适配部分已推迟

计划在 deepin-ports 仓库内新增 apps-translated 组件提供转译应用包。
计划申请 deepin-wine-helper 代码权限，调查是否能打包出 RISC-V/LoongArch 架构的对应软件包。
同步更新 deepin 仓库内的 wine 至上游最新版本。

关键设备适配

在 K3 上测试使用 RVA23 仓库并进行 benchmark。
修改 deepin-ports-kernel 的 workflow 以支持使用 GCC 15+ 构建。

其它部分已推迟

调研 guestfish 方案是否能统一 deepin-ports 的镜像打包工作流。
deepin-ports-image 重构

deepin-ports SIG 周报 (2026-05-22)

deepin-ports SIG — Fri, 22 May 2026 00:00:00 +0000

本周进展

关键设备适配进展预估 60%

已与厂商联系并针对发布的最新内核打包了一版 K3 镜像。
厂商在使用新内核后反映 K3 GPU 已能正常使用。
已发布 K3 的安装指南。

deepin-ports 维护

发布了两版 K1 镜像。
K1 镜像测试报告不通过，修复缺失包的问题后重新打包镜像。
接收来自开发板漂流计划的两份 K1 的测试报告。
适配各开发板的 ffmpeg patch 版本因为上游安全更新，正在重新打包。
已打包来自 Radxa 的 qcom 7.0 内核，适用于 Radxa Q6A 和 Q8B。

其它

向 Open Build Service 提交了允许在 scmsync 模式下 trigger service 的 PR。

下周规划

RVA23 仓库部分已推迟

争取 RVA23 RFC 能够尽快获得通过，以便正式确定技术规范。
进行一些基础库的重构，以便利用 RVA23 提升性能。
准备在 deepin-ports-image 中增加单独的 RVA23 仓库选项。
继续升级 rust 工具链至 1.88+。
升级 mesa 26.1.0。

RISC-V 转译应用适配部分已推迟

计划在 deepin-ports 仓库内新增 apps-translated 组件提供转译应用包。
计划申请 deepin-wine-helper 代码权限，调查是否能打包出 RISC-V/LoongArch 架构的对应软件包。
同步更新 deepin 仓库内的 wine 至上游最新版本。

关键设备适配

在 K3 上测试使用 RVA23 仓库并进行 benchmark。
修改 deepin-ports-kernel 的 workflow 以支持使用 GCC 15+ 构建。

其它部分已推迟

调研 guestfish 方案是否能统一 deepin-ports 的镜像打包工作流。
deepin-ports-image 重构

deepin-ports SIG 周报 (2026-05-15)

deepin-ports SIG — Fri, 15 May 2026 00:00:00 +0000

本周进展

deepin-ports 维护

更新了 k1 的 deepin 25.1 镜像。

其它

根据 TC 会议精神，提出两个需求，已被采纳并加入需求列表：
- deepin live 模式下应当写入 sources.list 以实现 live 模式下安装软件包
- deepin live 模式下应当在桌面显示水印，提示用户当前为 live 模式
开发板漂流计划：已寄出一块 K1 开发板。

下周规划

RVA23 仓库部分已推迟

争取 RVA23 RFC 能够尽快获得通过，以便正式确定技术规范。
进行一些基础库的重构，以便利用 RVA23 提升性能。
准备在 deepin-ports-image 中增加单独的 RVA23 仓库选项。
继续升级 rust 工具链至 1.88+。
升级 mesa 26.1.0。

RISC-V 转译应用适配部分已推迟

计划在 deepin-ports 仓库内新增 apps-translated 组件提供转译应用包。
计划申请 deepin-wine-helper 代码权限，调查是否能打包出 RISC-V/LoongArch 架构的对应软件包。
同步更新 deepin 仓库内的 wine 至上游最新版本。

关键设备适配

在 K3 上尝试使用 Imagination 开源驱动方案结合 Zink 启动桌面。
在 K3 上测试使用 RVA23 仓库并进行 benchmark。
修改 deepin-ports-kernel 的 workflow 以支持使用 GCC 15+ 构建。

其它部分已推迟

调研 guestfish 方案是否能统一 deepin-ports 的镜像打包工作流。
deepin-ports-image 重构

deepin-ports SIG 周报 (2026-05-08)

deepin-ports SIG — Fri, 08 May 2026 00:00:00 +0000

本周进展

RVA23 仓库进展预估 55%

已在新设备（amd64 + riscv64）上基于 deepin 25.1 叠加 RVA23 仓库并升级验证了仓库的可用性，无存在冲突的软件包。
已验证 mesa 26.1.0 可在现有 RVA23 仓库基线上构建。

关键设备适配进展预估 50%

观测到上游已正式发布了 K3 的 SDK，已在 deepin-ports-kernel 中增加了对 K3 6.18 内核和 u-boot 的构建。
已与厂商沟通，预计下周进行会议讨论 GPU 适配事宜。

deepin-ports 维护

为用户在浏览器端直接创建可一次写入的镜像，已发布 wasm-imager: 一个基于 WebAssembly 的镜像创建工具。
基于以上工具，在 deepin-ports SIG 网站上增加了镜像创建页面。该功能目前尚在测试阶段，待进一步验证。

其它

已收到 Radxa/高通有关开发者大会的邀请，将进行展位的准备工作。

下周规划

RVA23 仓库部分已推迟

争取 RVA23 RFC 能够尽快获得通过，以便正式确定技术规范。
进行一些基础库的重构，以便利用 RVA23 提升性能。
准备在 deepin-ports-image 中增加单独的 RVA23 仓库选项。
继续升级 rust 工具链至 1.88+。
升级 mesa 26.1.0。

RISC-V 转译应用适配部分已推迟

计划在 deepin-ports 仓库内新增 apps-translated 组件提供转译应用包。
计划申请 deepin-wine-helper 代码权限，调查是否能打包出 RISC-V/LoongArch 架构的对应软件包。
同步更新 deepin 仓库内的 wine 至上游最新版本。

关键设备适配

在 K3 上尝试使用 Imagination 开源驱动方案结合 Zink 启动桌面。
在 K3 上测试使用 RVA23 仓库并进行 benchmark。
修改 deepin-ports-kernel 的 workflow 以支持使用 GCC 15+ 构建。

其它部分已推迟

调研 guestfish 方案是否能统一 deepin-ports 的镜像打包工作流。
deepin-ports-image 重构

deepin-ports SIG 周报 (2026-04-30)

deepin-ports SIG — Thu, 30 Apr 2026 00:00:00 +0000

本周进展

RVA23 仓库进展预估 55%

尝试在 deepin next / RVA23 仓库推进 gcc 16。
在 deepin next / RVA23 仓库完成 rust 1.82 的升级，四大架构均完成构建。
在 deepin next / RVA23 仓库推进 mesa 26 及其依赖 (meson/vulkan/libdrm) 升级，四大架构均完成构建。

deepin-ports 维护

修复了 deepin-ports-kernel 的构建 workflow。
推送了 generic-revyos-617y 内核到 deepin-ports 内核仓库。

其它

参与 RISC-V Meetup Wuhan 并作有关 RVA23/next 仓库进展和 deepin 开发板漂流计划的报告。

下周规划

RVA23 仓库部分已推迟

争取 RVA23 RFC 下周内获得通过，以便正式确定技术规范。
进行一些基础库的重构，以便利用 RVA23 提升性能。
准备在 deepin-ports-image 中增加单独的 RVA23 仓库选项，并在 k3 上测试 RVA23 仓库。

RISC-V 转译应用适配部分已推迟

计划在 deepin-ports 仓库内新增 apps-translated 组件提供转译应用包。
计划申请 deepin-wine-helper 代码权限，调查是否能打包出 RISC-V/LoongArch 架构的对应软件包。
同步更新 deepin 仓库内的 wine 至上游最新版本。

其它部分已推迟

调研 guestfish 方案是否能统一 deepin-ports 的镜像打包工作流。
deepin-ports-image 重构

deepin-ports SIG 周报 (2026-04-17)

deepin-ports SIG — Fri, 17 Apr 2026 00:00:00 +0000

本周进展

RVA23 仓库进展预估 50%

尝试在 deepin next / RVA23 仓库推进 mesa 26 并推进部分包的升级。
- rust-bindgen-cli
- directx-headers
- libdrm
- meson
- spirv-tools
- spirv-llvm-translator-21
尝试在 deepin next / RVA23 仓库推进 llvm 22。

关键设备适配进展预估 40%

已与厂商讨论 GPU 适配相关事项。如果未能适配闭源驱动可能考虑开源 zink 方案或先使用软件渲染。
从上游重新拉取、打包和更新了 K3 的内核。

其它

已定于在下周于武汉举行的 RISC-V Meetup，deepin-ports 将作 deepin next 相关分享，并进行开发板漂流活动宣讲。

下周规划

RVA23 仓库部分已推迟

争取 RVA23 RFC 下周内获得通过，以便正式确定技术规范。
进行一些基础库的重构，以便利用 RVA23 提升性能。
准备在 deepin-ports-image 中增加单独的 RVA23 仓库选项，并在 k3 上测试 RVA23 仓库。

RISC-V 转译应用适配部分已推迟

计划在 deepin-ports 仓库内新增 apps-translated 组件提供转译应用包。
计划申请 deepin-wine-helper 代码权限，调查是否能打包出 RISC-V/LoongArch 架构的对应软件包。
同步更新 deepin 仓库内的 wine 至上游最新版本。

其它部分已推迟

调研 guestfish 方案是否能统一 deepin-ports 的镜像打包工作流。
deepin-ports-image 重构

deepin-ports SIG 周报 (2026-04-10)

deepin-ports SIG — Fri, 10 Apr 2026 00:00:00 +0000

本周进展

RVA23 仓库进展预估 50%

由于构建机器进行搬迁，尚未连接构建系统，本周暂无进展。

deepin-ports 维护

天气炎热，已将 4 台 SG2042 机器搬迁至有空调的调试机房，网络尚在配置中。
在调试间重新安装和配置 SG2044 机器。

其它

在 TC 会议上跟进了 ISO Live 体验相关的 RFC 事项。
预计在 4 月末将在武汉举行 RISC-V Meetup，已联系运营进行合作，届时将同步开展开发板漂流计划的宣讲和第一阶段的分发。

下周规划

RVA23 仓库部分已推迟

争取 RVA23 RFC 下周内获得通过，以便正式确定技术规范。
进行一些基础库的重构，以便利用 RVA23 提升性能。
准备在 deepin-ports-image 中增加单独的 RVA23 仓库选项，并在 k3 上测试 RVA23 仓库。

关键设备适配部分已推迟

等待厂商配合修复 GPU 问题。

RISC-V 转译应用适配部分已推迟

计划在 deepin-ports 仓库内新增 apps-translated 组件提供转译应用包。
计划申请 deepin-wine-helper 代码权限，调查是否能打包出 RISC-V/LoongArch 架构的对应软件包。
同步更新 deepin 仓库内的 wine 至上游最新版本。

其它部分已推迟

调研 guestfish 方案是否能统一 deepin-ports 的镜像打包工作流。
deepin-ports-image 重构

deepin-ports SIG 周报 (2026-04-02)

deepin-ports SIG — Thu, 02 Apr 2026 00:00:00 +0000

本周进展

RVA23 仓库进展预估 50%

llvm-toolchain-21 在 loong64 上已打包完成，基础仓库就绪。

仓库已在以下地址发布：

deb [trusted=yes] https://ci.deepin.com/repo/obs/deepin:/CI:/ports:/rva23/testing/ ./

deepin-ports 维护

deepin-ports SIG 页面前端：
- 更新了依赖，解决构建失败问题，暂时 pin vue 版本至 3.5.30 直到 vuetify 发布新版本。
deepin-ports-kernel 刷新上游版本：
- 弃用闭源补丁流程，现在 deepin-ports 仅支持完全开源的内核代码。
- 弃用树莓派 (bcm2711/bcm2712) 的 6.12 版本内核，保留 6.18 版本。
- 弃用 DC ROMA 1 的 5.15 定制内核。
- 更新 CIX P1 的内核至 2025Q4 SDK。
- 弃用 SG2042 的 6.6 内核。
- 将来自 collabora 的 RK3588 内核更名为 rk3588-collabora-619y。
deepin-ports 仓库：
- 针对 A7A 的相关变动，更新了 A733 的内核，后续镜像将提供两种规格 A7A 的支持。

下周规划

RVA23 仓库部分已推迟

争取 RVA23 RFC 下周内获得通过，以便正式确定技术规范。
进行一些基础库的重构，以便利用 RVA23 提升性能。
准备在 deepin-ports-image 中增加单独的 RVA23 仓库选项，并在 k3 上测试 RVA23 仓库。

关键设备适配部分已推迟

等待厂商配合修复 GPU 问题。

RISC-V 转译应用适配部分已推迟

计划在 deepin-ports 仓库内新增 apps-translated 组件提供转译应用包。
计划申请 deepin-wine-helper 代码权限，调查是否能打包出 RISC-V/LoongArch 架构的对应软件包。
同步更新 deepin 仓库内的 wine 至上游最新版本。

其它部分已推迟

调研 guestfish 方案是否能统一 deepin-ports 的镜像打包工作流。
deepin-ports-image 重构

deepin-ports SIG 周报 (2026-03-27)

deepin-ports SIG — Fri, 27 Mar 2026 00:00:00 +0000

本周进展

RVA23 仓库进展预估 45%

开始建立 deepin next 仓库，初始软件包主要为工具链。为保证隔离，仓库将独立于 deepin 主线和 deepin-ports 仓库。

已在 SG2044 (模拟 RVA23) 设备上测试上述仓库的基础可用性。
已在 ci.deepin.com 建立 deepin next 仓库，支持四大架构。目前依然使用 deepin-ports-keyring 签名。后续会将此仓库转移到可公开访问的路径下。
loong64 因为构建机内存不足，本周依然在重新尝试打包 llvm-toolchain-21。

deepin-ports 维护

已安排一台空闲的 DP1000 设备协助玲珑进行 RISC-V 架构软件包仓库初始化。
已与运营开始协商规划 deepin 开发板漂流计划，预计下周形成初步方案。

下周规划

RVA23 仓库部分已推迟

争取 RVA23 RFC 下周内获得通过，以便正式确定技术规范。
进行一些基础库的重构，以便利用 RVA23 提升性能。
准备在 deepin-ports-image 中增加单独的 RVA23 仓库选项，并在 k3 上测试 RVA23 仓库。

关键设备适配部分已推迟

等待厂商配合修复 GPU 问题。

RISC-V 转译应用适配部分已推迟

计划在 deepin-ports 仓库内新增 apps-translated 组件提供转译应用包。
计划申请 deepin-wine-helper 代码权限，调查是否能打包出 RISC-V/LoongArch 架构的对应软件包。
同步更新 deepin 仓库内的 wine 至上游最新版本。

其它部分已推迟

调研 guestfish 方案是否能统一 deepin-ports 的镜像打包工作流。
deepin-ports-image 重构

deepin-ports SIG 周报 (2026-03-20)

deepin-ports SIG — Fri, 20 Mar 2026 00:00:00 +0000

本周进展

RVA23 仓库进展预估 45%

RVA23 基础工具链基线提升已完成，开始进行部分包的性能优化。

已修改 dpkg 为 riscv64 默认使用 rva23u64 基线。
已修改 gcc-15 使用 rva23u64 ISA string 作为构建 flag。
已修改 llvm-toolchain-21 启用 rva23 基线。
已基于 rva23 基线重构 glibc。
除 loong64 因为构建机内存不足暂无法打包 llvm-toolchain-21，其余所有升级均在四大架构全部构建完毕。

deepin-ports 维护

已为 Radxa A7A 的两种音频芯片（AC101/AC101B）修改 u-boot 和内核，用户可以自行根据手中的设备进行选择。
- 以上修改已在 Radxa 寄送的 A7A 设备上测试完毕。相关 PR 已合入，对应产物等待推进仓库。

下周规划

RVA23 仓库部分已推迟

争取 RVA23 RFC 下周内获得通过，以便正式确定技术规范。
创建 RVA23 (next) 仓库并合入已构建出的软件包，然后继续进行 RVA23 基线提升工作。
准备在 deepin-ports-image 中增加单独的 RVA23 仓库选项，并在 k3 上测试 RVA23 仓库。

关键设备适配部分已推迟

等待厂商配合修复 GPU 问题。

RISC-V 转译应用适配部分已推迟

计划在 deepin-ports 仓库内新增 apps-translated 组件提供转译应用包。
计划申请 deepin-wine-helper 代码权限，调查是否能打包出 RISC-V/LoongArch 架构的对应软件包。
同步更新 deepin 仓库内的 wine 至上游最新版本。

其它部分已推迟

调研 guestfish 方案是否能统一 deepin-ports 的镜像打包工作流。
deepin-ports-image 重构

deepin-ports SIG 周报 (2026-03-06)

deepin-ports SIG — Fri, 06 Mar 2026 00:00:00 +0000

本周进展

RVA23 仓库进展预估 45%

本周对工具链的工作进行收尾测试，初步开始 RVA23 基线的打包验证。

四个架构上的 native 工具链均已打包完成，处于就绪状态。
交叉工具链在 amd64/arm64 上打包完成，在 loong64/riscv64 上的打包修复作为后续处理事项。
已将整个 rva23 项目设置为仅在 RVA23 profile 的 SG2044 上打包。
已更新 dpkg 调整 RVA23 编译参数，并两次构建成功，初步验证了基线提升的效果。

关键设备适配进展预估 40%

针对 SpacemiT K3 平台，本周完成了图形化验证，驱动等待厂商更新。

从厂商处获取了电源适配器，从而允许 typec DP 输出以调试图形界面。
成功进入 deepin 安装界面，安装成功后成功进入完整的 deepin 桌面。
GPU 驱动存在问题，已打包初步镜像供厂商调试使用。

deepin-ports 维护

收到用户关于 A733 A7A 设备的反馈，已查明是不同型号设备的硬件规格不一致导致的。
- 已收到来自 radxa 的 A7A 设备，但目前没有正常工作的 SD 读卡器。任务暂时延后。

下周规划

下周参加 FOSSAsia，顺延到下下周。

RVA23 仓库部分已推迟

争取 RVA23 RFC 下周内获得通过，以便正式确定技术规范。
创建 RVA23 (next) 仓库并合入已构建出的软件包，然后继续进行 RVA23 基线提升工作。
准备在 deepin-ports-image 中增加单独的 RVA23 仓库选项，并在 k3 上测试 RVA23 仓库。

关键设备适配部分已推迟

等待厂商配合修复 GPU 问题。

RISC-V 转译应用适配部分已推迟

计划在 deepin-ports 仓库内新增 apps-translated 组件提供转译应用包。
计划申请 deepin-wine-helper 代码权限，调查是否能打包出 RISC-V/LoongArch 架构的对应软件包。
同步更新 deepin 仓库内的 wine 至上游最新版本。

其它部分已推迟

调研 guestfish 方案是否能统一 deepin-ports 的镜像打包工作流。
deepin-ports-image 重构

deepin-ports SIG 周报 (2026-02-27)

deepin-ports SIG — Fri, 27 Feb 2026 00:00:00 +0000

本周进展

RVA23 仓库进展预估 40%

本周投入了大量精力进行工具链的升级和版本对齐，同时还打包了交叉编译的相关基础工具链。

SG2044 已成功部署基于 RVA23 模拟的 OpenSBI 固件，并顺利接入构建系统，作为 deepin 社区第一台完全符合 RVA23 标准的构建机，大幅提升了 RVA23 软件包的编译效率。
跟进 GCC 上游，向 GCC-15 Backport 了几个 RVA23U64 Profile 的支持补丁。完成了针对 -march=rva23u64 编译选项的构建验证。
交叉工具链方面，完成 gcc-15-cross / cross-toolchain-base 的升级：
- 给 cross-toolchain-base 的交叉编译增加了 loong64 的支持
- 给 binutils 的交叉编译增加了 loong64 和 riscv64 的支持
- 针对交叉工具链不一致导致的构建失败问题，升级对齐 debian 小版本：
  - glibc 2.42-12
  - linux 6.18.9
  - gcc 15.2.0-13
  - binutils 2.46-1
gcc-15 新版依赖 python-check-jsonschema 已打包
至此，面向 RVA23 的完整工具链已基本就绪，下周起将正式进入系统基线的切换与调整阶段

关键设备适配进展预估 40%

针对 SpacemiT K3 平台，本周与厂商进行了密切的联合调试，从 bootloader 到操作系统的全链路均打通。

bootloader 方面：
- 完成 K3 U-Boot 的测试运行，针对运行中发现的缺陷已整理 patch 并提交给厂商。
- u-boot + opensbi 自动持续构建已提交 deepin-ports-kernel 的 k3 分支，将在厂商公开发布代码后合并。
- esos 已完成打包，针对打包时遇到的问题，已整理 patch 并提交给厂商。
- spacemit-flash-dtbs 软件包已同步升级至 k3 最新版。
- bootloader 阶段工作基本收尾，目前正在编写面向用户的安装指南。
内核方面：
- K3 需要的 GPU 等固件已打包并推送至 deepin-ports 仓库。
- 通过厂商协助，实现使用 deepin gcc-15 工具链打包 K3 内核，自动构建代码已提交 deepin-ports-kernel 的 k3 分支，将在厂商公开发布代码后合并。
- 编译完成的内核包已推送至 deepin-ports 仓库。
系统方面：
- 在 deepin-ports-profiles 和 deepin-ports-image 中加入了 K3 的初步支持。
- 系统已成功引导至 CLI 命令行界面。
- 由于缺乏 Type-C DP+PD 扩展坞，使用 x11vnc 绕过物理输出进行了验证，成功驱动 K3 的 GPU 并运行 glmark2-es2 图形性能测试，证明硬件加速能力已就绪。

deepin-ports 维护

收到用户关于 A733 A7A 设备的反馈，已查明是不同型号设备的硬件规格不一致导致的。
- u-boot 现已对 A7A 提供两种二进制，分别指向 ac101/ac101b 两个 dtb 文件，用户可根据情况刷入。
- kernel 现已对 A7A 同时提供 ac101/ac101b 两种 dtb 文件，可根据 u-boot 选择。
- 已对安装文档进行修改已引导用户选择合适的 u-boot。
- 已向 radxa 要求 A7A 设备以供测试。
已对 imggpu 的闭源二进制包进行了重命名，后缀现在为 {ddk版本}-{bvnc}
- 同时对 profile 包中的依赖和配置也进行了修改。
在 deepin CICD 的 k8s 集群下搭建了监控平台，并给大部分较强算力的 rv 机器配置了监控，降低宕机排查时间。

下周规划

RVA23 仓库部分已推迟

争取 RVA23 RFC 下周内获得通过，以便正式确定技术规范。
创建 RVA23 (next) 仓库并合入已构建出的软件包，然后继续进行 RVA23 基线提升工作。
准备在 deepin-ports-image 中增加单独的 RVA23 仓库选项，并在 k3 上测试 RVA23 仓库。

关键设备适配部分已推迟

预计下周完成对 SpacemiT K3 的初步适配，至少支持 cli 系统的启动。

RISC-V 转译应用适配部分已推迟

计划在 deepin-ports 仓库内新增 apps-translated 组件提供转译应用包。
计划申请 deepin-wine-helper 代码权限，调查是否能打包出 RISC-V/LoongArch 架构的对应软件包。
同步更新 deepin 仓库内的 wine 至上游最新版本。

其它部分已推迟

调研 guestfish 方案是否能统一 deepin-ports 的镜像打包工作流。
deepin-ports-image 重构

deepin-ports SIG 周报 (2026-02-13)

deepin-ports SIG — Fri, 13 Feb 2026 00:00:00 +0000

祝大家春节玉快，阖家欢落！

本周进展

关键设备适配

已获取 K3 及代码，工作流将在厂商同步释放 SDK 时发布。

deepin-ports 维护

增加 apple-asahi-617y 内核。
增加 rk3566-mainline u-boot。
radxa-overlays-dkms。

RISC-V 转译应用适配

box64 0.4.0 已合并。实测可在 RISC-V 设备上成功运行 Linux 版 steam。

下周规划

RVA23 仓库部分已推迟

争取 RVA23 RFC 下周内获得通过，以便正式确定技术规范。
基于已有的高版本工具链，尝试开启 RVA23 优化的 Bootstrap，以便后续评估性能收益。

关键设备适配部分已推迟

预计下周正式启动针对 SpacemiT K3 芯片/设备的适配工作，评估内核与引导支持情况，具体进度以厂商通知为准。

RISC-V 转译应用适配部分已推迟

计划在 deepin-ports 仓库内新增 apps-translated 组件提供转译应用包。
计划申请 deepin-wine-helper 代码权限，调查是否能打包出 RISC-V/LoongArch 架构的对应软件包。
同步更新 deepin 仓库内的 wine 至上游最新版本。

其它部分已推迟

调研 guestfish 方案是否能统一 deepin-ports 的镜像打包工作流。

deepin-ports SIG 周报 (2026-02-06)

deepin-ports SIG — Fri, 06 Feb 2026 00:00:00 +0000

本周进展

RVA23 仓库进展预估 32%

本周完成了四大架构基础仓库的构建。

已在 rva23 仓库修复了 loong64 的部分包的构建
- rebuild 了 libffi (loong64 下未以 -fPIC 构建)
- 完成 llvm-21 的 stage1 和完全体构建
- 为 loong64 升级了 llvm-defaults 以使用 llvm-21
RVA23 仓库的全部工具链已就位。RVA 基线升级等待符合 RVA23 的构建机就位中。

关键设备适配

已向进迭时空请求 K3 设备及三件套（内核、驱动、bootloader）代码。等待后续中。

deepin-ports 维护

更新了 A733 (a733-radxa-515y) 的内核并解决了构建问题。
有用户报告 A733 的音频芯片在不同批次间型号不一致，可能需要引入 dtbo，预计下周会给出解决方案。

基础设施与文档建设

接收一台 Radxa Zero 3W，下周将开始适配。

RISC-V 转译应用适配

提交了 box64 0.4.0 升级的 PR，预计下周展开测试。

下周规划

RVA23 仓库部分已推迟

争取 RVA23 RFC 下周内获得通过，以便正式确定技术规范。
基于已有的高版本工具链，尝试开启 RVA23 优化的 Bootstrap，以便后续评估性能收益。

关键设备适配部分已推迟

预计下周正式启动针对 SpacemiT K3 芯片/设备的适配工作，评估内核与引导支持情况，具体进度以厂商通知为准。

RISC-V 转译应用适配部分已推迟

计划在 deepin-ports 仓库内新增 apps-translated 组件提供转译应用包。
计划申请 deepin-wine-helper 代码权限，调查是否能打包出 RISC-V/LoongArch 架构的对应软件包。
同步更新 deepin 仓库内的 wine 至上游最新版本。

其它部分已推迟

调研 guestfish 方案是否能统一 deepin-ports 的镜像打包工作流。

deepin-ports SIG 周报 (2026-01-30)

deepin-ports SIG — Fri, 30 Jan 2026 00:00:00 +0000

本周进展

RVA23 仓库进展预估 30%

本周继续进行 RVA23 仓库的工具链版本方面的收尾工作，同时递交 RFC 草稿。

已向 deepin RFC 仓库递交 RFC 18: 「建立 deepin RVA23 优化/next 仓库」。
已针对 RFC 收到的部分反馈做出了多轮修改和问题回应。
已在 rva23 仓库、在四大架构完成以下操作：
- llvm 21 stage1 和完整版本升级构建完成（loong64 架构除外）
- llvm-defaults 已升级为使用 llvm-21（loong64 架构除外）
- wasi-libc 已完成更新
目前工具链升级工作已收尾，预计下周可开始进入到 RVA23 的基线调整阶段。

关键设备适配

观察到进迭时空 K3 已发布，正在联系沟通适配相关事宜以获得相关代码。

deepin-ports 维护

为 linux-firmware backport Radxa Q6A 的相关固件以解决音频问题，已合并推送。

基础设施与文档建设

针对离线的双路 SG2042 高性能构建节点询问了管理方，并进行了系统的重新安装。
已将该节点重新纳入构建集群。

其它

已获得 UOS AI 代码访问权限，通过重新编译、修改使 UOS AI 成功在 RISC-V 设备上运行本地模型。
已提交 llama.cpp 相关构建参数至 UOS AI 项目组，要求修复 riscv64 架构的构建。
已对 UOS AI 相关组件包进行审计，针对一些本应标记为 all 架构的软件包，向 UOS AI 项目组提出整改。

下周规划

RVA23 仓库

争取 RVA23 RFC 下周内获得通过，以便正式确定技术规范。
基于已有的高版本工具链，尝试开启 RVA23 优化的 Bootstrap，以便后续评估性能收益。

关键设备适配部分已推迟

预计下周正式启动针对 SpacemiT K3 芯片/设备的适配工作，评估内核与引导支持情况，具体进度以厂商通知为准。

RISC-V 转译应用适配部分已推迟

计划在 deepin-ports 仓库内新增 apps-translated 组件提供转译应用包。
计划申请 deepin-wine-helper 代码权限，调查是否能打包出 RISC-V/LoongArch 架构的对应软件包。
同步更新 deepin 仓库内的 wine 和 box64 至上游最新版本。

其它部分已推迟

调研 guestfish 方案是否能统一 deepin-ports 的镜像打包工作流。

deepin-ports SIG 周报 (2026-01-23)

deepin-ports SIG — Fri, 23 Jan 2026 00:00:00 +0000

本周进展

RVA23 仓库进展预估 25%

本周主要集中在下一代 RISC-V 架构标准（RVA23）的底层工具链构建与版本对齐。

已与相关研发人员完成协调，初步确定了 RVA23 桌面系统的基线版本策略，准备与其它厂商达成一致。
已在 rva23 仓库、在四大架构完成以下操作：
- binutils 2.45 升级构建完成。
- gcc-15 stage1 stage2 和完整版本升级构建完成。
- gcc-defaults 已升级为使用 gcc-15。
- glibc 2.42 升级构建完成。
- dpkg 1.23.4 升级构建完成。
目前工具链升级工作已接近尾声，即将开始 llvm-toolchain-21 升级工作，工具链升级工作即将收尾并进入到 RVA23 基线调整阶段。

deepin-ports 维护

为 alsa-ucm-conf 提交来自 radxa 的 patch，目前 PR 正等待上机验证，预计将解决音频配置问题。
在内核构建工作流中升级了 Q6A 的内核到 6.18，相关产物已推送至 deepin-ports 仓库。
发布了搭载 deepin 25.0.10 和 6.18 内核的 Q6A 镜像。
deepin 25.0.10 发布版镜像已集成 RISC-V 64位 ISO，未来将实现与主线同步发布。
deepin 25.0.10 发布镜像已在 DP1000 台式机上进行测试并成功完成安装和运行。

基础设施与文档建设

修复并重新上线了 4 台此前离线的 SG2042 构建机器，恢复了集群算力。
已修复 sig-deepin-ports 的页面前端构建问题。
已在 sig-deepin-ports 的页面标注和区分 ISO 通用镜像的下载与设备镜像的下载。
已在 sig-deepin-ports 的页面醒目展示社区支持声明和默认密码信息。

其它

已配合运营完成 openRuyi 社区相关页面的文档提供与校对。

下周规划

RVA23 仓库

预计下周完成全部工具链版本升级的构建和验证。
在确认能够运行 RVA23 指令集的实体机就位后，正式启动 RVA23 的软件包基线提升工作。

关键设备适配

预计下周正式启动针对 SpacemiT K3 芯片/设备的适配工作，评估内核与引导支持情况，具体进度以厂商通知为准。

RISC-V 转译应用适配部分已推迟

计划在 deepin-ports 仓库内新增 apps-translated 组件提供转译应用包。
计划申请 deepin-wine-helper 代码权限，调查是否能打包出 RISC-V/LoongArch 架构的对应软件包。
同步更新 deepin 仓库内的 wine 和 box64 至上游最新版本。

其它部分已推迟

调研 guestfish 方案是否能统一 deepin-ports 的镜像打包工作流。

dde-shell 调试简明指南

DDE 桌面环境小组 — Mon, 19 Jan 2026 09:20:00 +0000

桌面环境组件的开发调试相比应用组件总会有或多或少的不同，本文就旨在提供一个快速简明的描述，给期望开发或调试 dde-shell 以及其插件的开发者一个参考，以便快速上手。

环境推荐

你实际上可以使用任意自己喜欢的 IDE/开发环境，方便起见，此处以下列环境作为基础。若你使用其他开发工具或环境，则需自己参照实际情况进行调整。

IDE: Visual Studio Code 或其衍生版本
- 推荐安装的插件
  - Native Debug (webfreak.debug) (用于使用 gdb 启动调试)
  - clangd (llvm-vs-code-extensions.vscode-clangd) (用于提供 C++ LSP)
  - CMake Tools (ms-vscode.cmake-tools) (用于初始的配置和构建)

推荐使用 VSCode 或衍生版本是因为 VSCode 目前事实上是主流 IDE。后附的三个插件均是 VSCode 官方仓库以及 Open VSX 仓库都可以获取到的。下面所涉及的配置文件主要会和 Native Debug 插件有一定相关性。

构建项目

事实上，dde-shell 的项目和常规 CMake 项目并无不同，常规的 CMake 配置和构建过程即适用于 dde-shell 项目。不过为了更好的 IDE 集成，建议确保 -DCMAKE_EXPORT_COMPILE_COMMANDS=ON 配置以便在构建目录中生成可供 clangd 消费的 compile_commands.json。

你亦可直接使用 CMake Tools 完成配置和构建，也是本文推荐的做法。好处是你还可以在 VSCode 中看到相关的单元测试，以及直接在 IDE 中点击相关按钮完成整个构建过程。

[!NOTE] 请注意：不要进行安装（make install / cmake --build build --target install），因为默认的安装位置是 /usr/local/bin，并非期望的位置。盲目手动安装意味着卸载也会非常困难。若要运行自己所构建的版本，请参阅后面的部分。

运行项目

dde-shell 项目在 DDE 桌面环境承载的责任包括使对应组件能够准确的在屏幕的指定位置进行展示。dde-shell 作为一个桌面环境外壳程序，自身也是由多个不同的插件构成的。dde-shell 需要通过参数来获知自己需要加载或排除加载哪些插件。对于任务栏组件而言，任务栏的部分插件也涉及到了一些额外的环境变量需要关心。

下面是一个适用于 VSCode + Native Debug 的构建和运行模板(.vscode/launch.json)：

{
 "version": "0.2.0",
 "configurations": [
 {
 "name": "Debug",
 "type": "gdb",
 "request": "launch",
 "target": "./build/shell/dde-shell",
 "cwd": "${workspaceRoot}",
 "valuesFormatting": "prettyPrinters",
 "env": {
 "TRAY_LOADER_EXECUTE_PATH": "/usr/libexec/trayplugin-loader",
 "TRAY_DEBUG_PLUGIN_PATH": "/usr/lib/dde-dock/plugins/:/usr/lib/dde-dock/plugins/system-tray/",
 "DISPLAY": ":0",
 "QT_QPA_PLATFORM": "dxcb",
 "LANGUAGE": "zh_CN.UTF-8",
 "QT_LOGGING_RULES": "*.debug=true;qt*.debug=false",
 "DDE_SHELL_PLUGIN_PATH": "/home/username/Sources/dde-launchpad/build/plugins/",
 "DDE_SHELL_PACKAGE_PATH": "/home/username/Sources/dde-launchpad/build/packages/",
 // "DDE_SHELL_PLUGIN_PATH": "/usr/lib/x86_64-linux-gnu/dde-shell/",
 // "DDE_SHELL_PACKAGE_PATH": "/usr/share/dde-shell/",
 "XDG_CURRENT_DESKTOP": "DDE",
 },
 "arguments": "-p org.deepin.ds.dock -p org.deepin.ds.dde-apps",
 "preLaunchTask": "Build (Debug)"
 },
 ]
}

以及对应的 .vscode/tasks.json

{
 "version": "2.0.0",
 "tasks": [
 {
 "label": "Build (Debug)",
 "type": "shell",
 "command": "cmake",
 "args": ["--build", "build", "-j4"]
 },
 {
 "label": "Run (x11)",
 "type": "shell",
 "command": "./build/shell/dde-shell",
 "args": [
 "-p", "org.deepin.ds.dock",
 "-p", "org.deepin.ds.dde-apps",
 "-p", "org.deepin.ds.example.bridge"
 ],
 "options": {
 "env": {
 "TRAY_LOADER_EXECUTE_PATH": "/usr/libexec/trayplugin-loader",
 "TRAY_DEBUG_PLUGIN_PATH": "/usr/lib/dde-dock/plugins/:/usr/lib/dde-dock/plugins/system-tray/",
 "DISPLAY": ":0",
 "QT_QPA_PLATFORM": "dxcb",
 "LANGUAGE": "zh_CN.UTF-8",
 "QT_LOGGING_RULES": "*.debug=true;qt*.debug=false",
 "DDE_SHELL_PLUGIN_PATH": "/home/username/Sources/dde-launchpad/build/plugins/",
 "DDE_SHELL_PACKAGE_PATH": "/home/username/Sources/dde-launchpad/build/packages/",
 "XDG_CURRENT_DESKTOP": "DDE",
 }
 }
 }
 ]
}

若只是从 VSCode 中运行，则事实上 .vscode/tasks.json 中的 Run (x11) 部分是不必要的。后者是供 vscode-task-runner 类工具调用使用的，这对目前的各类 Agent 助手类应用会更有帮助。

上述列出的环境变量和参数列表均为常用内容，对于各类 bug 很可能需要做出相应调整。例如：

加载自己构建的插件还是系统的插件？是否要加载其他外部插件（比如 dde-launchpad 插件？）（DDE_SHELL_PLUGIN_PATH/DDE_SHELL_PACKAGE_PATH）
测试其他语言的效果？（LANGUAGE）
使用自己构建的 tray-loader 或者加载自己构建的托盘插件？（TRAY_LOADER_EXECUTE_PATH/TRAY_DEBUG_PLUGIN_PATH）
确保日志输出？

另外，如果你要测试 TreeLand 环境下的 dde-shell，你需要移除 DISPLAY 环境变量并添加下面的环境变量（推荐另写一组或多组 launch configuration）：

// 窗口化 treeland
 "WAYLAND_DISPLAY": "wayland-0",
 "QT_QPA_PLATFORM": "wayland",
// 常规 treeland 会话
 "WAYLAND_DISPLAY": "treeland.socket",
 "QT_QPA_PLATFORM": "wayland",

结语

希望上述快速指南对你有帮助。若有问题，欢迎在 GitHub linuxdeepin/developer-center 仓库发起讨论。你也可以考虑添加相关实时群聊来与开发者进行交流（ Telegram / Matrix ）。

deepin-ports SIG 周报 (2026-01-16)

deepin-ports SIG — Fri, 16 Jan 2026 00:00:00 +0000

本周进展

RVA23 仓库进展预估 20%

RVA23 方案已在本周 TC 例会上进行讨论，初步结论如下：
- 开 deepin next/unstable 分支用于 RVA23（及后续更多实验性项目）
- 引入 gcc-15，并修改 target (rva23u64)，关闭 LTO
- 修改 /usr/share/perl5/Dpkg 下的 flag 以增加 -march=
- 是否引入自动向量化待评估
- rebuild 或升级 glibc
- 可能需要升级/修改/rebuild的软件包：
  - 基础：binutils （需要 patch）
  - 数学：openblas（调参数），fftw，gmp/mpfr
  - 密码：openssl（OPENSSL_riscvcap 调整（动态）），gnutls
  - 压缩：zlib/xz/zstd
  - 媒体：ffmpeg/gstreamer，libjpeg，x264/x265/dav1d
  - 运行时：python，v8/nodejs，llvm (21)，rust，go (1.24 rva22)（rebuild go 包？）
  - 图形：mesa，pixman，cairo
  - 桌面：qt6
- 确定一批需要 rebuild 的软件包列表
- 由于 hwcap 支持问题，使用 6.18 内核，并需要注意 abi 变动
- 本阶段使用 SG2044 + 模拟 V 等缺失拓展实现，等待接下来支持 rva23 的设备发布
- 参考 TC 会议纪要：https://github.com/deepin-community/SIG/blob/master/TC/Meeting%20Minutes/2026-01.md
已向仓库新增 gcc-15 包并创建 PR，预计下周进行构建，月内集成。后续将在此基础上增加 RVA23 支持。

RISC-V 转译应用适配进展预估 10%

生态现状调研：
- 针对商店中的 deepin-box64 向 deepin-wine 开发组提出质询，了解到该包已处于消极维护状态。deepin-ports SIG 预备介入此事。
- 针对商店中的 deepin-wine* 的多架构可用性向 deepin-wine 开发组提出质询，了解到该组无意提供 riscv64/loong64 架构的相关软件包。deepin-ports SIG 预备介入此事。
运行时打包验证：
- 已基于 arm64 deepin-wine-runtime 自行修改至 riscv64/loong64 架构并推送 deepin-ports 仓库。
- 已基于 amd64 deepin-wine{10,8}-stable 自行修改至 riscv64/loong64 架构（增加 box64 转译依赖）并推送 deepin-ports 仓库。
已在 DP1000 设备上验证上述 wine 程序运行状态良好。

其它

deepin 仓库浏览器：
- 增加了应用商店查包功能
- 已在 deepin 论坛推广使用：https://bbs.deepin.org/post/294965
deepin-ports SIG 页面：
- 新增 asciinema 支持，以便在安装文档中提供更直观的命令行操作。
- 效果如下：
deepin-ports-kernel：
- 已打包支持树莓派 4/5 的内核，后续将做树莓派设备适配的更新。

下周规划

RVA23 仓库

调研 Ubuntu 的 Architecture-Variant 方案。
调试 SG2044 的模拟 RVA23 方案。
尝试构建 gcc-15，并升级 gcc-defaults 至 15，将后续在 RVA23 仓库内集成。
尝试构建更新版本的 binutils，并打入 rva23 相关 patch，将后续在 RVA23 仓库内集成。

RISC-V 转译应用适配

计划在 deepin-ports 仓库内新增 apps-translated 组件提供转译应用包。
计划申请 deepin-wine-helper 代码权限，调查是否能打包出 RISC-V/LoongArch 架构的对应软件包。
同步更新 deepin 仓库内的 wine 和 box64 至上游最新版本。

其它

修改现有设备的安装文档，在一些用户易混淆的地方使用 asciinema，降低用户使用门槛。
调研 guestfish 方案是否能统一 deepin-ports 的镜像打包工作流。
自购串口线，在 DP1000 设备上测试最新的 deepin RISC-V ISO，若测试无误即发布到公开仓库。

deepin 25.0.10 正式版 DDE 移植简要指南

DDE 移植兴趣小组 — Wed, 07 Jan 2026 00:00:00 +0000

deepin 25.0.10 已经发布一段时间了，而即将发布的 deepin 25.0.10 正式版镜像也会包含对应版本的 DDE 组件。为了方便各个其它发行版的包维护者可以更方便的移植 DDE 到对应的发行版，这里提供一篇简要的移植指南，用以描述常见的移植问题和解决方案。

下面对项目名称的称呼均以 GitHub 对应的原始仓库名为准。

概览

相对于 deepin 25 最初的正式版本，在 deepin 25.0.10 中并不存在较大幅的架构调整，而是以缺陷修复作为研发的重心，并涵盖了一些小功能的更新。本阶段中有部分组件的首位版本号存在调整，另存在一些注意事项，详情请参见后续的描述。

由于这些项目的版本间互相影响，我们建议移植人员参照 deepin 25 中实际所使用的包版本进行打包，下面会对主要的部分进行详细说明。

需要注意的是，由于此文章编写时间早于新 ISO 的发布时间，故最终版本镜像中使用的版本可能高于下面列出的版本。我们尽可能确保此文章的准确性，但若您需要获取 ISO 镜像中使用的确切软件版本列表，请挂载 ISO 后参阅 LIVE/FILESYS{T,0,1}.MAN/live/filesystem.manifest 路径对应的文件的内容。

另外，由于前述 manifest 文件包含了 ISO 所附带的所有软件包的版本信息，而 DDE 移植并不需要关注整个列表，你可以参考 deepin-community/deepin-desktop-environment 提供的几个 Meta 包中描述的依赖关系，来了解哪些软件包和 DDE 有关。

主要组件

DTK 与 DTK6

DTK 是 DDE 组件与应用的基础依赖，适用于deepin 25 正式版的版本参照如下：

project	package name¹	version
dtkcommon	libdtkdata	5.7.26
dtklog	libdtklog	0.0.6
dtkcore	libdtkcore5	5.7.26
dtkgui	libdtkgui5	5.7.26
dtkwidget	libdtkwidget5	5.7.26.1
dtkdeclarative	libdtkdeclarative5	5.7.26
qt5integration	dde-qt5integration	5.7.26
qt5platform-plugins	dde-qt5xcb-plugin	5.7.26
dtk6core	libdtk6core	6.0.46
dtk6gui	libdtk6gui	6.0.46
dtk6widget	libdtk6widget	6.0.46.1
dtk6declarative	libdtk6declarative	6.0.46
qt6integration	dde-qt6integration	6.0.46
qt6platform-plugins	dde-qt6xcb-plugin	6.0.46

本次 DTK 组件大部分版本号以及相对应的平台插件等版本号均已对齐，例外的有 dtkcommon 与 dtklog。可参照上表进行打包。

关于 qt5platform-plugins，现有的 dwayland 插件可能对非 DDE 环境（例如 KDE）的 wayland 用户存在影响，可参照 linuxdeepin/developer-center#7217 打对应的 patch 规避影响。

另外，之前版本的打包采取了 dtk5 与 dtk6 分仓库进行打包的方案，就于上述（在 deepin 25.0.10 镜像中使用的 DTK）版本，您暂时仍然需要在 dtk6blah 仓库中获取对应的 tag。目前正在向回归到同一仓库打包的方案进行过度，且过度即将完成，即未来版本将会不再需要使用 dtk6blah 仓库，只需 dtkblah 即可。对于此事项的进展可以关注移植小组的 Telegram 或 Matrix 群聊。

DDE 主要组件

下面仅涉及变化较大或影响较广的组件。其余未涉及的组件可正常参照最新 tag 进行打包与移植。

在 alpha 与 beta 阶段使用 1.99.z 系列版本号的项目现均启用了 2.0.z 版本号，以表示相关的行为变动。针对 dde-shell 所提供库的依赖的 SOVERSION 仍为 1，不受打包版本号的影响。

下面涉及到的组件的版本参照如下：

project	package name¹	version
deepin-desktop-schemas	deepin-desktop-schemas	6.0.13
dde-daemon	dde-daemon	6.1.64
dde-session	dde-session	2.0.9
dde-session-ui	dde-session-ui	6.0.35
dde-session-shell	dde-session-shell	6.0.50
dde-application-manager	dde-application-manager	1.2.37
dde-shell	dde-shell	2.0.19
dde-launchpad	dde-launchpad	2.0.17
dde-tray-loader	dde-tray-loader	2.0.17
dde-application-wizard	dde-application-wizard-daemon-compat	0.1.21
dde-clipboard	dde-clipboard	6.1.16
deepin-service-manager	deepin-service-manager	1.0.17
dde-services	dde-services	1.0.12
dde-appearance	dde-appearance	1.1.71
dde-api	dde-api	6.0.29
treeland-protocols	treeland-protocols	0.5.1
dde-network-core	libdde-network-core	2.0.74
dde-control-center	dde-control-center	6.1.58
dde-file-manager	dde-desktop	6.5.106
dde-launcher	被 dde-launchpad 取代，不再使用
dde-dock	被 dde-shell 取代，不再使用
startdde	已被废弃，不再使用

dde-application-manager

由于涉及到诸多关于应用识别的改善，故建议总是使用最新版本。

dde-session-shell

请注意，当前项目获取 tag 的源码仓库现在变为了 https://github.com/linuxdeepin/dde-session-shell-snipe 。

dde-shell

dde-shell 在本段时间的更新迭代中，修复了若干关于任务栏图标识别问题以及图标错位的问题。对于比较受到争议的 cgroup 识别问题也给出了配置项运行用户进行微调。对于移植，也处理了高版本 Qt 的一些兼容性问题。

我们假定您要移植的目标发行版使用的 Qt 版本大于 6.8.2，如果早于此小版本，请阅读上一篇（正式版时的）博客来了解相关的补丁信息。

dde-shell 在 alpha 中为修正一个特定问题所包含的一个变更依赖另一个 Qt Wayland 的 patch：

https://github.com/deepin-community/qt6-wayland/pull/12

若你所移植的目标发行版不接受此补丁，则可考虑对 dde-shell 项目 revert 于此相关的对应 commit：

https://github.com/linuxdeepin/dde-shell/commit/77cac3d5a346728f6678eedc77fce404f0ffd8b6

dde-launchpad

dde-launchpad 现仅支持以 dde-shell 插件的形式被最终用户使用。因而，打包 dde-launchpad 现需要先打包 dde-shell，并确保用户最终使用的是 dde-shell。

dde-session

我们已在 deepin 23 beta3 起放弃了对 deepin-kwin wayland 的支持，DDE 后续所有 wayland 相关的支持均由 treeland 提供。请参见后续的 Treeland 段落。

deepin-kwin 环境

此部分相对 beta 也未存在较大变动，但由于此组件的重要性，方便起见，此处重新阐述 beta 阶段的变化：

deepin-kwin 对 Qt 的版本依赖切换到了 Qt 6，不过值得注意的是，当前的 deepin-kwin 并非从上游 kwin 6.x 中 fork 出来的，而是基于 uos 20 版本的 kwin 5.27.x 进行的 qt6/kf6 迁移，并且由于一些原因，其二进制可执行的文件名恢复到了 kwin，这会导致与上游原版 kwin 的冲突。

就于此事项的详细介绍，请参见 https://github.com/orgs/linuxdeepin/discussions/11471 讨论。对于移植人员，我们建议考虑下面三种方案：

使用 Qt 6 的 deepin-kwin，放弃与上游 kwin 的共存支持。
继续使用 deepin-kwin 5.27，尽管存在一些问题，但此版本仍然可保证和上游版本 kwin 共存。
考虑打包 Treeland 环境。

Treeland 环境

Treeland 环境尽管目前仍然是实验性支持，但目前 treeland 构建不再需要事先构建 waylib 与 qwlroots。

下面涉及到的组件的版本参照如下。对于位于非 linuxdeepin 组织的软件包，此处一并给出了组织名：

package	version
treeland-protocols	0.5.1
treeland	0.7.8
ddm	0.2.3

DDM

尽管 DDM 目前是基本功能可用状态，DDM 目前仍相对而言不够稳定。对于打包移植而言，建议采用其他DM来启动用户级的treeland。

对于其它 DM，只需要打包时安装 usr/share/wayland-sessions/treeland-user.desktop 即可。

Qt 补丁

我们假定您要移植的目标发行版使用的 Qt 版本大于 6.8.2，如果早于此小版本，请阅读上一篇（正式版时的）博客来了解相关的补丁信息。

如果你在 Treeland 下遇到小 launchpad 无法输入中文的问题，可以打下面的 patch，但是该 patch 目前尚未进行完整测试，可能存在一些问题。

https://codereview.qt-project.org/c/qt/qtbase/+/611940

建议忽略移植的组件

dde-api-proxy

此组件的存在目的是给部分仍在依赖 deepin 20/23 所提供的 D-Bus 服务的第三方组件提供兼容。DDE 和 deepin 第一方应用均不依赖这些旧的 D-Bus 接口，且此组件目前不被 deepin 自身所需，所以此项目不应当被移植。

deepin-anything

尽管被部分 DDE 组件依赖，但均为可选。anything 提供了内核模块，对于滚动发行版移植可能不友好，可能移植并不能得到很高的体验改善。

若忽略 deepin-anything 移植，则下列组件也应当被忽略（因为依赖了 deepin-anything）：

dde-grand-search

dde-application-wizard

尽管此项目初衷之一是提供可移植的模块化卸载服务，但并未达到理想状态。尽管事实上可被顺利移植，此项目可以考虑忽略。缺失此组件并不会影响 DDE 主要功能。

已知问题

下述问题是已知问题，需酌情处理。

deepin-kwin 与 kwin 原版的共存问题

目前由于 Qt 6 版的 deepin-kwin 与上游原版 kwin 存在一些同名可执行文件/配置文件，故无法做到 deepin-kwin 与 kwin 的共存。若要移植 x11 会话，选择如下：

使用 Qt 5 版本的 deepin-kwin（目前 openSUSE 移植的做法如此）
打包 deepin-kwin，并声明与上游 kwin 的冲突（会导致 KDE x11 与 DDE x11 会话无法共存，目前 Arch Linux 移植的做法如此）

由于 dde-session 的依赖关系，这也会导致如果仅希望使用 deepin 的 wayland 会话，也会受到上述问题的影响而无法使 KDE 与 DDE 共存，此问题会在后续进行解决来确保允许仅移植 DDE wayland，从而使 DDE wayland 和 KDE 可以无冲突的共存。

任务栏托盘部分，插件的背景颜色异常

这个问题是目前移植过程中发现的已知问题，但暂时没有时间定位分析。若您移植过程中遇到此问题，可暂时忽略，当然也欢迎协助定位并提交 PR :)

获取移植帮助

如果您希望得到移植相关的帮助，请考虑加入我们 DDE 移植小组的在线交流群（下列房间有桥接，任选其一即可），一起展开相关的交流：

Matrix 群：#dde-port:deepin.org
Telegram 群：https://t.me/ddeport

一个项目可能有多个软件包，此处的包名仅列出了此项目在 deepin 发行版中具有代表性的包名 ↩︎ ↩︎

deepin-ports SIG 周报 (2025-12-26)

deepin-ports SIG — Fri, 26 Dec 2025 00:00:00 +0000

本周进展

SG2044 适配进展预估 90%

已在本地 SG2044 EVB 上成功验证 6.12 内核通用 ISO 镜像的启动与安装流程。
SG2044 正式成为继 DP1000 之后，deepin 第二款实现 ISO 通用镜像完整支持的 RISC-V 设备。
集成 SG2044 补丁的 6.12 内核的通用 ISO 镜像已发布至 deepin-ports SIG 下载页，后续的详细功能验证与测试工作已移交相关测试人员安排。

DDUC 2025 进展预估 80%

已完成部分参展设备的系统重装和配置。剩余设备将在 DDUC 当日上午完成调试。

RVA23 仓库进展预估 15%

已对照部分发行版的 RVA23 适配状况进行了简单评估。仓库划分将很快开始。

MilkV Titan 适配进展预估 30%

已接收来自 UltraRISC 的 MilkV Titan 相关补丁，经代码审查后 PR 已合并。
已将基于补丁构建的通用 ISO 镜像发送至厂商以供测试。

其它

应香橙派厂商要求，提供了 deepin 25 兼容认证证书，以助力推进其生态。
修改了通用镜像的安装指南，现在包括了部分适配通用镜像的 deepin-ports 设备的安装方法。

下周规划

下周适逢元旦佳节，SIG 组成员休假，暂无具体开发任务规划。

deepin-ports SIG 周报 (2025-12-18)

deepin-ports SIG — Thu, 18 Dec 2025 00:00:00 +0000

本周进展

香橙派适配进展预估 10%

接收一台 OrangePi AIPro 20T 开发板。
已与香橙派开发人员沟通，先行临时镜像暂不涉及 bootloader 和内核部分。
已完成临时基础镜像交付，可开机进入命令行界面。

SG2044 适配进展预估 70%

已在 deepin-ports-profiles 包中修复 u-boot 启动菜单相关 bug。
已指导测试人员修改启动选项开机，已可进入 deepin 桌面。
新的测试镜像已发布。

RVA23 仓库进展预估 10%

已评估仓库划分方案，拟切出 testing/next（名称待定）分支，全架构构建，版本至少对齐 rva23 支持的最低要求，并作为 rva23 支持的基础，未来将服务 deepin 下个版本。

DDUC 2025 进展预估 50%

已与运营协商，向部分厂商和开发者提出邀请。
deepin-ports SIG 展位部分文案已准备完毕。

其它

通用 ISO 镜像正在 DP1000 新设备上进行 6.6/6.12 内核安装测试。
通用 ISO 镜像正在 SG2044 设备上进行 6.12 内核安装测试。

下周规划

DDUC 2025：进行参展设备选择、安装和调试。
RVA23 仓库：评估软件版本基线，设置工作流。
SG2044 适配：等待测试结论，如有 bug 则继续 debug。
香橙派适配：等待厂商交付完整的内核代码和启动文档。

deepin-ports SIG 周报 (2025-12-12)

deepin-ports SIG — Fri, 12 Dec 2025 00:00:00 +0000

镜像更新

在 Radxa Dragon Q6A 设备上搭配 UFS 测试了 deepin 25 镜像，运行桌面环境成功。
新增了以下设备的 deepin 25 测试镜像:
- sg2044:
  - 20251208-100625

内核更新

deepin-ports-kernel 项目：
- 增加了 revyOS 提供的 SG2044 6.18 内核。
- 由于 Zhihe A210 u-boot 持续构建失败，现从列表中移除。
ports-kernel 仓库对已有内核更新了新构建的版本。

文档

安装指南

新增了如下设备的安装指南：
- Sophgo SG2044
- Radxa Dragon Q6A

活动

deepin-ports SIG 将携设备参与本月的 DDUC 2025 并进行展示。

其它 SIG / 非 SIG 事务

deepin 仓库查看器现已部署自动更新脚本，将不定期自动刷写数据。

deepin-ports SIG 周报 (2025-12-05)

deepin-ports SIG — Fri, 05 Dec 2025 00:00:00 +0000

镜像更新

在 SG2044 设备上测试了 deepin 25 镜像，运行桌面环境成功。
deepin-ports-images 项目：
- 现可创建 sg2044 镜像，预计下周可发布。

内核更新

deepin-ports-kernel 项目：
- 增加了u-boot 发布版本工作流，后续将可以手动将 u-boot 发布到对象存储的 release 目录。
- 修改了u-boot 快照版本工作流，后续每次 u-boot 自动构建将上传至 rolling 目录。
- 设置了 deepin-ports-kernel.0x7f.cc 作为 deepin-ports-kernel 的临时仓库地址，托管在 Cloudflare R2 对象存储上。
  - rolling 快照版本产物默认保留 14 天，并在发布 7 天后标记为非频繁访问存储。

应用更新

deepin-ports-profiles 项目：
- 增加了 sg2044 的配置包。

测试

合并了以下镜像的测试报告：
- eic7700: deepin 25 Preview 20250729-125156 测试报告

活动

接收到一台 DP1000 台式机，用作镜像 debug。

deepin-ports SIG 周报 (2025-11-28)

deepin-ports SIG — Fri, 28 Nov 2025 00:00:00 +0000

镜像更新

新增了以下设备的 deepin 25 测试镜像:
- a733:
  - 20251121-162850

内核更新

deepin-ports-kernel 项目：
- 跟随上游刷新了 Rockchip 内核补丁。
- 增加了 clang 编译支持。
- 增加了 LFRon 提供的 SM8150 6.17 内核。

应用更新

deepin-ports 仓库:
- 修复了 img-gpu-bin-ddk242-a733 因 git lfs 打包出错的问题。

活动

接收了 SG2044 的文档，开始进行适配。

文档

安装指南

改进了 A733 设备的安装指南。

网页

sig-deepin-ports 项目：
- 增加了全局搜索功能。
- 调整了部分界面风格。

deepin-ports SIG 周报 (2025-11-21)

deepin-ports SIG — Fri, 21 Nov 2025 00:00:00 +0000

镜像更新

在 Radxa Cubie A7Z 设备上测试了 deepin 25 镜像，运行桌面环境成功。
新增了以下设备的 deepin 25 测试镜像:
- a733:
  - 20251118-115143

内核更新

deepin-ports-kernel 项目：
- 新增上传工作流，后续将自动上传 u-boot 产物到对象存储。
- 修复了 collabora RK3576 主线 u-boot 构建。
- 增加了 revyOS 提供的 SG2044 6.17 内核。
- 更新了 revyOS 提供的 SG2042 6.17 内核。

活动

获得一台 SG2044 机器，即将开始进行适配。
甲辰计划实习活动即将结束，已对现有 PR 进行了清理和加速处理。

deepin-ports SIG 周报 (2025-11-14)

deepin-ports SIG — Fri, 14 Nov 2025 00:00:00 +0000

镜像更新

在 DshanPi A1 设备上测试了 deepin 25 镜像，运行桌面环境成功。

内核更新

deepin-ports-kernel 项目：
- 增加了 collabora 提供的 RK3576 主线 u-boot。
- 为所有 rk3588-collabora uboot 支持的设备增加了构建。
- 为所有 rk3576-collabora uboot 支持的设备增加了构建。
- 在 rk3576-collabora uboot 为 DshanPi A1 增加了支持并导入了上游设备树。

应用更新

尝试为 Allwinner A733 内置的 IMG GPU 适配 mesa-ddk242、增加相关二进制驱动包。
deepin-ports-profiles 项目:
- 为 a733 修复了 aic8800 的固件路径。

文档

安装指南

新增了如下设备的安装指南：
- Allwinner A733
- Rockchip

网页

sig-deepin-ports 项目：
- 更新了「设备支持矩阵」的数据。

deepin-ports SIG 周报 (2025-11-07)

deepin-ports SIG — Fri, 07 Nov 2025 00:00:00 +0000

镜像更新

deepin-ports-images 项目：
- 为 a733 镜像配置了 profile 并合并了 boot 和 root 分区。
完成 rockchip 通用镜像的适配，在 rock5b 上进行了测试。
在 Radxa Cubie A7Z 设备上实现了 deepin 镜像的运行，预计下周开始进一步适配。
新增了以下设备的 deepin 25 测试镜像:
- rockchip:
  - 20251103-111909
  - 20251103-114144

内核更新

deepin-ports-kernel 项目：
- 增加了 radxa 提供的 A733 u-boot。
- 为 radxa 提供的 A733 u-boot 修改：
  - 拆分了原仓库的构建流程。
  - 提升 BOOTM_SIZE 以启动更大的内核和 initrd。
  - backport ufetch 命令。
  - backport booti 命令的压缩支持以启动 deepin 内核。
  - 调整默认环境变量以启动压缩内核启动支持。
  - 使用系统 arm 工具链编译 u-boot。
- 修复了 Radxa 提供的 A733 5.15 内核的构建流程，使得 bsp 相关选项被打开。

应用更新

deepin-ports-profiles 项目:
- 增加了 a733 的配置包。
  - 为 a733 增加 Radxa 提供的 img-bxm-dkms 内核驱动包。
deepin-ports 仓库:
- 增加了 ports-board-allwinner 仓库，提供 Allwinner (主要是 A733) 的驱动和编解码器支持。

文档

网页

sig-deepin-ports 项目：
- 进一步清理了代码，并在项目中完全使用 TypeScript。

deepin-ports SIG 周报 (2025-10-31)

deepin-ports SIG — Fri, 31 Oct 2025 00:00:00 +0000

镜像更新

deepin-ports-images 项目：
- 现可创建 rockchip 通用镜像，预计下周可发布。
- 默认使用 deb 包替代玲珑预装软件。
- 增加基础镜像缓存以极大提升构建速度。
- 使用 falloc 替代 dd 创建镜像，极大提升镜像创建速度。
- 自动判断内网/外网环境以切换到更快的镜像。
- 新增 GitHub 镜像打包 Workflow。

内核更新

deepin-ports-kernel 项目：
- 增加了 collabora 提供的 RK3588 主线 u-boot。
- 新增 PKG_DEPS 配置以避免无必要的 override。
- 新增 CIX 提供的 P1 6.6 内核。
- 新增 Radxa 提供的 Dragon Q6A 6.17 内核。
- 新增 Radxa 提供的 Rockchip 的 6.1 内核。
- 为 Rockchip 6.1 内核增加:

应用更新

deepin-ports-profiles 项目:
- 增加了 cix-p1 的配置包。
- 增加了 rockchip 的配置包。
  - 由于内核问题，为 rockchip 配置包暂时禁用 deepin-anything 服务。
  - 为 rockchip 配置包增加 u-boot 配置。
deepin-ports 仓库:
- 增加了 ports-board-rockchip 仓库，提供 Rockchip 的编解码器支持。

deepin-ports SIG 周报 (2025-10-24)

deepin-ports SIG — Fri, 24 Oct 2025 00:00:00 +0000

镜像更新

deepin-ports SIG 开始进行 Radxa Cubie A7Z 和 Rock5B 的适配工作。
deepin-ports-images 项目：
- 开始 Radxa Cubie A7Z 的初步适配，并增加了镜像配置。
新增了以下设备的 deepin 25 测试镜像:
- a7z:
  - 20251023-174830
  - 20251023-212347

内核更新

deepin-ports-kernel 项目：
- 增加了 Radxa Dragon Q6A 的 6.17 内核。
- 增加了 Radxa 提供的 Allwinner A733 的 5.15 内核，由 a7z-radxa-515y 更名而来，提供 Radxa 下所有 Allwinner A733 设备的通用支持。
- 增加了 Radxa 提供的 Rockchip 的 6.1 内核，提供 Radxa 下所有 Rockchip 设备的通用支持。
ports-kernel 仓库增加了上述内核打包好的 deb 软件包。

应用更新

尝试为 ports-apps 仓库加入来自 Radxa 的 rsetup 支持。

测试

测试了以下镜像：
- k1: deepin 25 Preview 20250804-152839 测试报告
- th1520: deepin 25 Preview 20250928-121959 测试报告
针对 RuyiSDK 论坛上有关 TH1520 测试的反馈，对报告进行了修改和补充说明。

文档

安装指南

新增了如下设备的安装指南：
- T-Head TH1520
为 T-Head TH1520 安装指南增加了 SD 卡启动的说明。

网页

sig-deepin-ports 项目：
- 为「支持矩阵」增加多架构显示功能
- 为网页中引用的 JSON 数据配置了类型注解。
- 修复和优化了首页按钮的排版。
新增 deepin-repo-viewer 项目，可通过 deepin-repo-viewer.pages.dev 访问并查询 deepin 绝大部分公开仓库内的软件包版本信息。

活动

开始筹备 deepin 的 RVA23 支持计划，调研可行的方案。
调整了 GitHub Project 的甲辰计划看板，增加了分类信息以便优先处理软件包的修复 PR。

deepin-ports SIG 周报 (2025-10-17)

deepin-ports SIG — Fri, 17 Oct 2025 00:00:00 +0000

镜像更新

新增了以下设备的 deepin 25 测试镜像:
- q6a:
  - 20251014-163626

内核更新

deepin/kernel 审阅并接收了 SG2042/SG2044 的支持 patch:
deepin-ports-kernel 项目：
- 为 q6a 内核补全 USB 声卡驱动
- 增加了知合计算 A210 6.6 内核的构建
- 增加了知合计算 A210 u-boot的构建

文档

安装指南

新增了如下设备的安装指南：
- T-Head TH1520 (eMMC)
在 SpacemiT K1 安装指南中提及 Ky X1 的兼容方法。

测试报告

th1520: deepin 25 Preview 20250928-121959 测试报告

活动

接收两位新的甲辰计划实习生。
为甲辰计划实习生增加 GitHub 的 Project 看板，以便更快地协助和参与 PR 的评审。
获得一台 DP1000 整机，对已有镜像进行了测试。
新闻稿：deepin 25 成功适配瑞莎 Dragon Q6A，开启高性能 ARM 桌面体验！
寄出一台 MUSE Pi Pro 用于甲辰计划打包。

其它 SIG / 非 SIG 事务

Ham Radio SIG: gridtracker 已上架 deepin 应用商店。
为社区配置了 deepin 社区宽带，提升了内部工作效率。

deepin-ports SIG 周报 (2025-09-26)

deepin-ports SIG — Fri, 26 Sep 2025 00:00:00 +0000

镜像更新

deepin-ports-images 项目：
- q6a 镜像增加了 ports-board-radxa-q6a 仓库支持。
- 不再提供 deepin 23 的镜像构建。
- /etc/product-info 的内容现已使用正确的方式写入。
- ports-tmpfix 仓库已被移除预置。
- 创建 EFI 分区时，现使用 mkfs.fat 而非 mkfs.fat -F 32。
- 对设备默认设置 RESUME=none 禁用 STD 休眠。

应用更新

增加了 ports-board-radxa-q6a 仓库以提供 q6a 特定软件包支持。
增加了 radxa-alsa-config rockchip-alsa-config 包以尝试提供音频支持。
deepin-ports-profiles 项目：
- 增加了 rockchip-alsa-config 依赖。
由于不再使用，deepin-ports 仓库移除 ports-tmpfix 组件。
为 mesa 引入 patch 以修复 LLVMpipe 问题。

活动

接收一位新的甲辰计划实习生。
寄出一台 lpi4a 用于甲辰计划测试。
重写了 RFC 0013 (electron 打包提案) 的草稿，并将其标记为等待审阅。

其它 SIG / 非 SIG 事务

Ham Radio SIG: 将对应的无线电相关软件包转移到 hamradio 组维护。
发布了使用 deepin 利用 GitHub Actions 进行打包的自动化流程。
- 在 deepin 论坛上同步发布了内容：白嫖 GitHub Actions，一键打包 deepin deb 软件包
发布了将 deepin ISO 镜像转换为包含持久化分区的 LiveUSB 的脚本。
- 在 deepin 论坛上同步发布了内容：轻松创建持久化、可保存数据的 deepin live USB 镜像

deepin-ports SIG 周报 (2025-09-19)

deepin-ports SIG — Fri, 19 Sep 2025 00:00:00 +0000

镜像更新

deepin-ports-images 项目：
- 修复了 x-systemd.device-timeout 不生效的问题，降低了挂载的等待时间。
- 增加了 mkfs_helper 方便创建不同的文件系统，并默认 4k 对齐。
新增了以下设备的 deepin 25 测试镜像:
- q6a:
  - 20250918-174812
验证了 q6a 的 deepin 镜像和 ubuntu 镜像的功能可用性，接收来自 radxa 的 q6a 镜像测试报告。

应用更新

发现了 packagekit riscv64 版本未更新，已修复。
为 grub2 打上了上游 patch，以使用 rdtime 而非 rdcycle 指令。

内核更新

接收了来自超睿的内核 patch，审阅测试中。

文档

修改了 deepin-ports SIG 的目标:
- 负责 deepin 多种架构、多种设备的适配（尤其是无法通过标准的主线 iso 适配、需要额外支持的），并进行针对性的软件包构建、镜像构建、Bug 修复等工作。

活动

获得一块 Radxa Cubie A7Z 开发板，即将开始进行适配。

deepin-ports SIG 周报 (2025-09-12)

deepin-ports SIG — Fri, 12 Sep 2025 00:00:00 +0000

镜像更新

deepin-ports-images 项目：
- 后续镜像构建将包括 deepin-desktop-environment-ll 包，并使用 ll-cli 预装应用，以修复在非 riscv64 架构下预装包列表不全的问题。
- 提供了 linglong 的内网镜像支持，以便在内网构建时进行加速。
- 增加了构建镜像时写入 grub.cfg 配置文件的功能。
- 增加了 q6a 的 GRUB 配置文件，并修复了了启动参数，以支持在非 sd 卡启动。
- 由于打包 tarball 时并不存在 network-manager 和 locales，为相关的 hook 进行了禁用。
- 增加了 q6a 的 genimage 配置，新镜像提供整个 .img 格式的文件，可直接进行写入。
- 新的 q6a 镜像将预装内核 header 和 aic8800 驱动。
重新发布了 tarball 镜像，验证并解决了 issue 12157 中 riscv64 tarball 中库文件损坏的问题。
新增了以下设备的 deepin 25 测试镜像:
- tarball:
  - 20250908-140807
- q6a:
  - 20250908-150501
  - 20250908-225014
  - 20250908-231253

应用更新

deepin-ports-profiles 项目：
- 现支持 q6a 设备，并增加了相应的配置文件和驱动依赖，增加模块加载配置文件以修复蓝牙问题。

内核更新

deepin-ports-kernel 项目：
- arm 内核打包时，现在会使用 GitHub 提供的原生 arm worker。
- 在非 cross 打包环境下，打包会产生 linux-headers 包。
- 在非 cross 打包环境下，不再安装 cross 工具链并设置 CROSS_COMPILE 变量。
ports-kernel 仓库增加了基于 radxa-pkg 源码构建的 aic8800 的 dkms 模块包。
ports-kernel 仓库增加了 q6a 的 header 包。
修复了 q6a 内核因为 run-parts 新版行为修改导致无法安装内核的问题。

文档

网页

在「镜像下载」页面区分了 RISC-V 和 ARM 架构，分别展示各自的镜像。

活动

由于 deepin-ports SIG 现在接手 ARM 设备适配，且 LoongArch 架构的主线支持已足够成熟，已在 TC 例会中要求更新 deepin-ports SIG 的目标。

deepin-ports SIG 周报 (2025-09-05)

deepin-ports SIG — Fri, 05 Sep 2025 00:00:00 +0000

镜像更新

在 deepin-ports-images 内同时支持了 Dragon Q6A 的镜像构建
deepin-ports-images 现在可以在没有独立 boot 分区的情况下创建 efi 分区了

应用更新

为 sg2042 预装 mtd-utils 以便写入 bootloader 到 MTD 中，对应的操作步骤已经写入安装指南。

内核更新

更新了 sg2042 的内核到 6.16.4 以修复 nvme 识别的问题。
由于 cross 编译的 linux-headers 二进制为宿主架构，为所有 cross 构建的内核关闭构建 linux-headers 包
deepin-riscv-kernel 同时接受 q6a-radxa-615y 的 arm 内核构建。

文档

安装指南

新增了如下设备的安装指南：
- Sophgo SG2042

活动

（上周）deepin 参展 elexcon 2025。详细介绍请参阅公众号新闻：deepin 亮相 elexcon2025 深圳国际电子展，全面展示 RISC-V 生态建设新成果
为 OSPP 学生寄出一台 MUSE Pi Pro 以便更好完成项目。
为甲辰计划实习生寄出一台 LicheePi 4A。
甲辰计划迎来两名新实习生。
获得一块 Radxa Dragon Q6A 开发板，开始进行适配。

deepin-ports SIG 周报 (2025-08-22)

deepin-ports SIG — Fri, 22 Aug 2025 00:00:00 +0000

镜像更新

为 th1520 的启动配置移除了 hidev0p7 的无用选项。

应用更新

chromium 139 版本已在以下架构完成构建，将在测试完成后推入主仓库：
- riscv64
- amd64
- arm64

内核更新

由于 deepin 主线内核 riscv64-desktop-* 已有稳定的构建工作流，此内核不再在 deepin-riscv-kernel 中提供。
观测到处于开发分支的 eic7700 6.12 内核，现于 deepin-riscv-kernel 中跟踪观测。

活动

筹备参展 elexcon 2025 的海报和材料。
- 海报制作完毕，设计稿如下：

deepin-ports SIG 周报 (2025-08-15)

deepin-ports SIG — Fri, 15 Aug 2025 00:00:00 +0000

镜像更新

现在 sg2042 镜像的内核默认使用 6.16 版本。
由于 u-boot-menu 配置现在由 deepin-ports-profiles 提供，镜像创建脚本中除定制镜像以外的对应配置文件均被移除。
所有镜像均预装 deepin-ports-keyring，因此 [trusted=yes] 从 deepin-ports 源配置中移除。
由镜像生成脚本定制的 u-boot-menu 文件现在将被安装至 usr/share/u-boot-menu/conf.d/99-custom.conf 以避免覆盖默认配置。
新增了以下设备的 deepin 25 测试镜像:
- sg2042:
  - 20250812-205045

应用更新

由实习生提交的 chromium 139 版本正在打包测试中。
deepin-ports-keyring 已被创建并包含在 ports-profiles 中，将在 deepin-ports 各镜像中预装。
deepin-ports-profiles 现在包含各个设备的 u-boot-menu 配置。

内核更新

仓库不再提供 th1520 的 5.15 内核。
为内核构建流程增加引入外部 patch 的支持。
为以下内核增加 cjktty 支持：
- eic770x-rockos-66y
- k1-spacemit-66y
- sg2042-upstream-66y
- th1520-revyos-66y

活动

新闻稿：RISC-V World Day

deepin-ports SIG 周报 (2025-08-08)

deepin-ports SIG — Fri, 08 Aug 2025 00:00:00 +0000

镜像更新

现在 k1 镜像的内核已更新为使用 deepin-riscv-kernel 构建工作流的产出版本。
由于 hwe 仓库位置变更，更新了 hwe 仓库的地址。
由于 hwe 仓库位置变更，再次更新了 hwe 仓库的地址，并同时将一部分 ci.deepin.com 的地址换成了正式仓库的地址。
- 已有用户可将 stable 源替换为 deb https://community-packages.deepin.com/deepin/beige/ crimson main community commercial 以提升访问速度。
- 已有用户可将 testing 源替换为 deb https://proposed-packages.deepin.com/beige-testing/ unstable/crimson main community commercial 以提升访问速度。
- 已有用户可将 hwe 源替换为 deb https://community-packages.deepin.com/hwe-25/ unstable main community commercial 以提升访问速度。
修改内核参数以修复 sg2042 6.16 内核在 MilkV Pioneer 上桥片失灵导致 USB 不工作的问题。
在镜像生成脚本中新增了免安装器（预先创建用户）的镜像支持。
镜像生成脚本新增 k1-cloud，以支持生成在云端环境（bianbu cloud）中开箱即用的镜像，仍在调试中，对应配置等待合并。
新增了以下设备的 deepin 25 测试镜像:
- k1:
  - 20250804-121920
  - 20250804-152839
- k1-cloud:
  - 20250806-180508

应用更新

deepin-ports 仓库 ports-board-spacemit-k1 支持仓库新增打包的 esos.elf 以固定内核对应的版本。
deepin-ports 仓库 ports-imggpu 已更新 k1 的 DDK 24.2 firmware 和驱动二进制。
旧的 ddk232 对应的 mesa 分支已不再使用，已删除。
由于 deepin 环境下 glx 打开 zink 存在问题，暂时移除 eic7700 对应的 mesa 中的强制 zink 补丁。
为所有基于 Imagination GPU 的设备通过 Recommends 方式预装 vulkan 驱动。
为 eic7700 打包来自 rockos 的 ap12275-firmware 固件包，并设置为预装。
在deepin-ports 仓库 ports-apps 中新增 code-server 应用。
deepin-ports 仓库 ports-gcc14 组件被 hwe 仓库替代，已删除。
应用商店因为仓库地址错误，首页无内容，已向应用商店维护组反馈，等待下一次更新修复。
- 如需临时体验，可修改 /etc/apt/sources.list.d/appstore.list 为 deb https://com-store-packages.uniontech.com/appstore-V25 crimson appstore

内核更新

deepin-ports 仓库内 k1 内核新增使用 deepin-riscv-kernel 构建工作流的产出。
- 旧的 k1 内核已从 ports-kernel 仓库移除。
因为众多报错无法构建，暂时移除 jh7110 的 6.12 上游内核打包工作流。
sg2042 现在切换为同时提供 6.6(LTS) 6.12（LTS） 6.16（最新）内核。
不再提供单独的 unmatched 的主线内核。

文档

安装指南

新增了如下设备的安装指南：
- SpacemiT K1

活动

由于堆积开发板过多且缺乏有效测试，针对现有实习生开展『开发板领养计划』。

deepin-ports SIG 周报 (2025-08-01)

deepin-ports SIG — Fri, 01 Aug 2025 00:00:00 +0000

镜像更新

由于 hwe 仓库已合入 gcc-14 相关组件，deepin-ports 仓库 ports-gcc14 组件将弃用并将在不久后删除。
现在 eic7700 镜像的内核已更新为 rockos 上游的最新版本 6.6.88。
现在 generic 通用 ISO 已修复 dp1000 上的 glibc 问题且集成新版内核，具备对 dp1000 的支持，dp1000 成为首个获得 deepin 官方主线支持的 RISC-V SoC，详细介绍请参阅后续的公众号新闻。
由于 generic 通用 ISO 已支持 dp1000，旧的 dp1000 定制镜像已被归档。
新增了以下设备的 deepin 25 测试镜像:
- eic7700:
  - 20250729-125156
- generic:
  - 20250728-172422
  - 20250729-143705

应用更新

由于关键依赖包更新尚未推送，以下软件包本周暂无法推送至 hwe 仓库：
- mesa 25
- wine
超睿对先前 glibc 的 PR 进行了解释，并公布了测试报告
修复了在 k1 上未正确拷贝 esos.elf 导致无法启动的问题，已通过 deepin-ports-profiles 更新。

内核更新

更新了 eic7700 的内核和 bootloader 以便支持更多开发板，例如 EIC7700 SBC。
修复了 eic7700 的构建 bug（导致 ddr 固件选择错误）。
完善了 u-boot 构建流程，为一部分设备打上 ufetch 支持补丁（目前 eic7700 和 k1 已可用）
由于 k1 内核已普遍采用 6.6 版本，不再构建旧的 k1 u-boot 和 6.1 内核。
更新 k1 的内核到最新的 k1-bl-v2.2.y 分支。

基础设施

于甲辰计划接收一台 MilkV Meles 用于测试。
于甲辰计划接收一台 EIC7700 树莓派用于测试。

活动

新一轮的甲辰计划实习生招聘开始了，详情可见 deepin 公众号或 RuyiSDK 社区。
预备对甲辰计划实习生开放部分 RV 设备的 SSH 访问权限，基础设施正在设置中。

deepin-ports SIG 周报 (2025-07-25)

deepin-ports SIG — Fri, 25 Jul 2025 00:00:00 +0000

镜像更新

后续更新的 rv 镜像将默认添加 hwe 仓库，以提供更高版本的 GPU 驱动和 GCC 版本，以及依赖它们的更新软件包。

应用更新

打包了 llvm 20 和 mesa 25，将推入 hwe 仓库提供更好的驱动支持。
为 Chromium 系的应用打上对应 patch，修复 RDCYCLE 在 RISC-V 新版内核被设置为特权指令，进而导致崩溃的问题。影响以下应用：
- electron 各版本
- 依赖 electron 的应用需要升级 electron
- chromium
修复了 Chromium 构建问题 #5487538
升级了 box64 应用到最新版本，并为其打开了 box32 功能以兼容更多应用。
验证了 WPS Office 可通过 box64 在 RISC-V 平台上运行。
为辅助 box64 更好地工作，尝试在 amd64/arm64 架构上打包 wine。
- 尝试为 wine 打开 WoW64 功能。
- 尝试升级 khronos-api 到最新版本，尝试升级 vulkan 全家桶到 1.4。
  - gcc-12 有潜在 bug 导致 spirv-tools 编译失败，已临时绕过，标记待修复：#115824
尝试打包 felix86 以提供 RISC-V 上的 Steam 和游戏支持。
由超睿提供 patch，修复了 glibc 在部分情形下随机出现的以下崩溃问题：
- Fatal glibc error: ../npctl/pthread_mutex_lock:94 (_pthread_mutex_cond_lock): assertion failed: mutex->__data.__owner == 0

内核更新

修复了因未开启 DRM_AMD_DC_FP 导致 RDNA2 显卡在 RISC-V 上不可用的问题。
修复了 amdgpu 代码中对不带向量拓展的 isa string 替换 v 导致 isa 变成 r64* 的问题。
接收了来自超睿对 PCIE Bar 空间修改的 PR。

测试

（上周）测试了以下镜像：
- th1520: deepin 25 Preview 20250711 103950 测试报告

基础设施

接收一台 MUSE Pi Pro 用于适配与测试。

活动

（上周）deepin 参展 RISC-V 中国峰会。详细介绍请参阅公众号新闻：deepin 亮相 2025 RISC-V 中国峰会，展现开源生态无限可能！

deepin-ports SIG 周报 (2025-07-11)

deepin-ports SIG — Fri, 11 Jul 2025 00:00:00 +0000

镜像更新

默认使用 6.6 内核构建 th1520 镜像，默认对 th1520 使用主线 openSBI。
新增了以下设备的 deepin 25 测试镜像:
- th1520:
  - 20250707-135951
  - 20250707-164130

应用更新

为 deepin-ports-profiles 移除对 th1520-vendor-opensbi 的硬依赖。

内核更新

向 deepin-ports 仓库推送了最新的 th1520-revyos-66y 内核，并设置为后续构建镜像的默认内核。
跟随上游同步更新了 th1520 的启动固件。

测试

针对 th1520 5.10 和 6.6 内核镜像展开测试工作。

文档

网页

为 deepin-ports SIG（本站）：
- Blog RSS 对接至 deepin planet (planet.deepin.org)
添加了甲辰计划和 RuyiSDK 的友情链接。

基础设施

一台 Pioneer 损坏查明是内核问题，已寄修排查反馈问题。
一台 MUSEbox 损坏，已寄修。

活动

deepin 现已加入 RuyiSDK 社区，并在 RuyiSDK 社区论坛设立专区，后续将同步发布周报进展和新闻。
完成参展 RISC-V 峰会的设备清单和周边的准备，下周 RV 中国峰会见！

deepin-ports SIG 周报 (2025-07-04)

deepin-ports SIG — Fri, 04 Jul 2025 00:00:00 +0000

镜像更新

由于 deepin-screen-recorder-plugin 在仓库中被移除，且新版 deepin-desktop-environment-extras 尚未集成，本周暂不可打包新镜像。
- 拟下周更新 TH1520 镜像。

应用更新

为 xorg 增加了部分 GLES 支持补丁。
为 jh7110 th1520 eic7700 k1 的 ffmpeg 针对主分支修改进行了 rebase。
协助厂商适配新版 electron 应用，推进 deepin 25 nodejs 更新 (18 -> 20)。
- 拟下周验证各版本 electron 可用性。

测试

测试了以下镜像：
- eic7700: deepin 25 Preview 20250627-155140 测试报告

文档

安装指南

新增了如下设备的安装指南：
- StarFive JH7110 (SD 卡)
- ESWIN EIC7700 (SD 卡 / eMMC / SATA / NVMe)

网页

为 deepin-ports SIG（本站）：
- 优化了移动端显示
- 为 blog 和文档内容增加了 TOC
- 为 blog 和文档增加了 RSS 支持，文件均为 atom1 格式：
  - 现可通过 feed.blog.xml 订阅「博客」内容。
  - 现可通过 feed.installdocs.xml 订阅「安装文档」内容。
  - 现可通过 feed.testdocs.xml 订阅「测试报告」内容。

基础设施

为社区其中一台 SG2042 安装了 6.14 内核并重新接入构建集群。
为第三方打包方便，新建了 deepin 打包工作流仓库（现施工中）

活动

继续筹备参展 RISC-V 峰会的海报和材料。

deepin-ports RISC-V 测试流程与模板 v0.1

deepin-ports SIG — Fri, 27 Jun 2025 00:00:00 +0000

本文档旨在为 deepin 移植到 RISC-V 架构提供一套标准化、可复现的测试流程。该文档将随测试工作逐渐完善。

0. 注意事项

0.1 测试条件

根据 RFC2119 制定以下规则，用于确定测试是否继续进行：

必须 (MUST):

任何情形下出现与陈述相悖的行为或结果，都将导致测试流程终止。

禁止/不得 (MUST NOT):

任何情形下出现与陈述相符的行为或结果，都将导致测试流程终止。

应该 (SHOULD):

当出现与陈述相悖的行为或结果时：如果文本仅有一条陈述，可选择忽略该结果并继续测试流程；如果文本存在多条陈述，仅大部分陈述内容均与当前结果相符时可忽略该结果并继续测试流程；未达到忽略条件的结果出现将导致测试流程终止；同一小节的测试不得忽略结果超过 3 次。

不应该 (SHOULD NOT):

当出现与陈述相符的行为或结果时：如果文本仅有一条陈述，可选择忽略该结果并继续测试流程；如果文本存在多条陈述，仅大部分陈述内容均与当前结果相悖时可忽略该结果并继续测试流程；未达到忽略条件的结果出现将导致测试流程终止；同一小节的测试不得忽略结果超过 3 次。

可以/可能 (MAY):

当出现与陈述相符或相悖的行为或结果时，均可继续进行测试流程，相应行为或结果应被记录。

0.2 支持等级划分

根据能够进入的最高章节的测试流程，将设备支持等级划分为 1-10 级，等级格式为 X(最高章节).Y(最高小节)：

0. 不支持

硬件不满足基本要求，或在可预见的未来无法被支持。
设备将从设备支持列表中除名，如果存在镜像，镜像将被删除。

1. 仅可安装，无法启动

完成了系统镜像的写入，但设备无法从该镜像成功引导至 bootloader 之后阶段。说明镜像的 bootloader 或内核存在严重问题。
镜像将被标记为不可用并隐藏

2. 基本命令行支持

系统可成功启动至命令行 Shell，核心系统（内核、init、systemd）工作正常，但图形功能完全缺失或无法启动。
镜像将被标记为不可用并隐藏

3. 基本图形化支持

图形化登录界面（Greeter）可以启动，并可登录桌面，但完全依赖 CPU 进行软件渲染（如 llvmpipe）。无硬件图形加速。
镜像将被标记为不可用并隐藏

4. DDE 桌面

DDE 桌面环境核心组件均可正常工作，提供稳定的基本桌面体验，但图形加速不可用，仅能以软件渲染模式运行。

5. 图形化支持

具备 2D/3D 硬件加速能力，提供完整的 DDE 桌面特效支持。
镜像达到 Preview 发布标准

6. 完整的 deepin 环境

所有 deepin 内置应用程序均可正常启动和使用，系统功能完整。
镜像达到 Preview 发布标准

7. 开箱即用的 deepin 环境

核心外设（如有线网络、USB、音频）无需手动配置即可自动驱动并正常工作。
镜像达到 Preview 发布标准

8. 完整支持

所有板载硬件功能（如 Wi-Fi、蓝牙、VPU、NPU）均得到驱动支持和功能验证。
镜像达到发布标准

9. 具备兼容性的完整支持

系统具备良好的软件兼容性。
镜像达到发布标准

10. RISC-V，崛起

系统高度完善，性能优化良好，达到或接近 amd64/arm64 水准。

1. 硬件设置篇

1.1 硬件基本状况

操作

通过任何渠道获得该设备，如果无法获得设备，请立即向 mentor 报告。
尝试接入电源并开启设备。

条件

设备 必须 (MUST) 存在并可被测试者实际接触和操作。
设备 必须 (MUST) 能够通过某种方式开机，且 不得 (MUST NOT) 发生起火、爆炸等使设备不可用的状况。

1.2 硬件基本信息

操作

查阅设备的基本信息，包括：
- 厂商名称
- SoC（核心型号、核心数、支持的指令集架构）
- 内存（类型，安装方式）
- 存储（类型，安装方式）
- 板载功能单元如 GPU、VPU、NPU 等
- I/O 接口（USB 端口、HDMI/DP、音频、网络接口）
- 板型（ATX、ITX、开发板类型）
- 调试接口（如 UART）位置和参数（波特率等）
- ......
查阅设备的厂商，获取安装文档。

条件

设备 必须 (MUST) 存在任何可访问的说明文档。
设备 必须 (MUST) 支持至少 rv64gc 指令集拓展。
- 设备 可以 (MAY) 支持 v 拓展等其它拓展指令集。
设备 必须 (MUST) 存在存储器或存储器插槽， 应该 (SHOULD) 支持至少 16G 存储空间。
设备 应该 (SHOULD) 具备至少 2GB 内存。为获得良好桌面体验，可以 (MAY) 具备 4GB 或以上内存。
设备 必须 (MUST) 存在可重复使用的写入系统镜像的方法。
设备 必须 (MUST) 具备启动 linux 系统的能力。
设备 应该 (SHOULD) 提供或能够连接一个串口控制台用于调试。
设备 应该 (SHOULD) 通过某种方式连接到互联网。
设备 应该 (SHOULD) 具有厂商提供的安装文档。
设备 不得 (MUST NOT) 存在无法关闭或兼容的安全启动/启动锁。

2. 系统写入与安装篇

2.1 镜像获取与校验

操作

从 deepin-ports 镜像发布页或指定地址下载系统镜像文件和对应的校验文件。
校验下载的镜像文件。

条件

镜像文件 必须 (MUST) 成功下载。
镜像文件的校验和 必须 (MUST) 与校验文件中的记录一致。如果出现不一致的状况，请立即向 mentor/镜像创建者报告。

2.2 固件与 Bootloader 设置

操作

根据厂商文档，判断设备是否需要预先刷写特定版本的固件或 Bootloader（如 U-Boot）。
如果设备存在需要刷写的固件
- 根据厂商文档，检查并刷写推荐版本的固件。
如果设备不需要额外刷写固件
- 跳过本小节

条件

如果设备存在需要刷写的固件
- 镜像 必须 (MUST) 无报错地刷写 bootloader。

2.3 写入系统镜像

操作

根据设备文档，准备启动介质并写入镜像。

条件

镜像 必须 (MUST) 无报错地写入存储设备。

3. 基础命令行篇

3.1 bootloader 启动

操作

在串行控制台中执行引导命令（或等待自动引导）。
观察日志，确认 bootloader 启动并准备开始引导启动。
如果存在启动菜单，确认菜单存在对应的启动条目。

条件

串口控制台 应该 (SHOULD) 显示 bootloader 的启动日志。
串口控制台 不应该 (SHOULD NOT) 在 bootloader 阶段输出致命性的错误日志。
如果存在启动菜单
- 启动菜单 必须 (MUST) 包括至少一条合法的启动项，对应的选项 应该 (SHOULD) 存在内核、initrd 等字段。
如果设备需要设备树
- 使用的设备树文件 应该 (SHOULD) 与设备型号对应。

3.2 内核启动

操作

观察内核解压和启动信息（dmesg 输出）。
等待一定时间后，尝试切换键盘的 NumLock/CapsLock。

条件

串口控制台 应该 (SHOULD) 显示 Linux 内核的启动日志。
内核 不得 (MUST NOT) 在早期启动阶段出现 Kernel panic 或致命错误。
切换键盘 NumLock/CapsLock，对应指示灯 应该 (SHOULD) 相应地变化。
initrd 必须 (MUST) 被内核正确加载。

3.3 initrd 启动

操作

观察启动日志，确认 initrd 启动，根文件系统 (rootfs) 被成功挂载。

条件

initrd 不得 (MUST NOT) 因报错进入 fallback 命令行。
根文件系统 必须 (MUST) 被成功挂载。
plymouth 界面 可能 (MAY) 显示。

3.4 systemd 启动

操作

观察启动日志，确认 systemd init 进程被成功拉起，并开始启动系统服务。
启动完成后，在终端执行 systemctl --failed 查看是否有失败的服务。

条件

systemd init 进程 必须 (MUST) 被启动。
大部分关键服务 应该 (SHOULD) 被成功启动。
启动服务过程中 可能 (MAY) 出现非关键服务长时间等待或启动失败。
systemd 不应该 (SHOULD NOT) 因关键服务启动失败进入 fallback 命令行。

3.5 基本环境验证

操作

如果启动后直接进入图形化 greeter，可按 Ctrl+Alt+F2 切换到 tty2。
进入命令行，使用默认密码登录系统。
执行以下命令：
- 执行 ip link 查看网络接口状况。
- 执行 uname -a 查看内核版本。
- df -h / mount 查看磁盘挂载情况。
- 如果存在 fastfetch 命令，执行 fastfetch 命令。

条件

Ctrl+Alt+F[1-12] 必须 (MUST) 能给切换到对应 tty。
登录提示 必须 (MUST) 弹出并能输入。
默认密码 必须 (MUST) 能够登录并进入 shell 命令行。
不应该 (SHOULD NOT) 提示密码错误或其它认证方面的错误。
以上命令 应该 (SHOULD) 能够执行，并且输出的信息与预期相符。

4. 基本图形功能篇

4.1 显示服务启动

操作

如果需要连接显示器，检查对应的连接线是否接好。
观察显示器输出。

条件

显示器 必须 (MUST) 显示 deepin 的图形化登录界面。
使用 Ctrl+Alt+F[2-6] 应该 (SHOULD) 能切换至 tty 虚拟终端并显示登录提示，Ctrl+Alt+F1 应该 (SHOULD) 能切回图形登录界面。

4.2 图形化登录

操作

在登录界面输入正确的用户名和密码。
点击登录或按回车。

条件

系统 必须 (MUST) 成功完成登录并尝试启动会话。
不应该 (SHOULD NOT) 提示密码错误或其它认证方面的错误。

4.3 基本桌面会话

操作

观察。

条件

系统 必须 (MUST) 至少能渲染出 DDE 桌面环境的基本形态。（即使非常卡顿）。
桌面 应该 (SHOULD) 至少显示出壁纸、任务栏（Dock）和桌面图标的轮廓或实际内容。
会话 不应该 (SHOULD NOT) 在成功登录后数秒内崩溃并返回到登录界面。

5. DDE 桌面体验篇

5.1 核心交互

操作

观察桌面。
移动鼠标，查看光标是否跟随。
点击任务栏上的启动器图标。
右键点击桌面。
尝试在桌面上框选。
尝试使用 DDE 的快捷键。

条件

DDE 应该（SHOULD） 正常渲染：
- 桌面壁纸与桌面图标
- 任务栏、任务栏托盘图标、托盘图标弹出菜单
动画和窗口特效 可以 (MAY) 正常显示。
鼠标光标 应该 (SHOULD) 正常渲染并平滑移动，不应该 (SHOULD NOT) 出现闪烁、撕裂或卡顿。
任务栏（Dock）、启动器（Launcher）、桌面右键菜单 必须 (MUST) 能够响应点击操作并正常显示。
DDE各快捷键 应当（SHOULD） 正常工作， 不应该 (SHOULD NOT) 在键盘按键与快捷键按下时产生冲突或卡顿。

5.2 窗口管理

操作

从启动器打开“文件管理器”和“终端”。
尝试拖动、最大化、最小化、关闭窗口。
尝试使用 Alt+Tab 切换窗口。

条件

窗口 必须 (MUST) 可以被拖动、缩放、最大化、最小化和关闭。
窗口切换功能 应该 (SHOULD) 正常工作。
窗口操作 不应该 (SHOULD NOT) 导致桌面环境（dde-shell）崩溃。

5.3 控制中心与系统托盘

操作

观察系统托盘，点击托盘右侧的插件区域，展开控制面板。
- 尝试调节音量、设置网络。
从启动器打开“控制中心”
- 查看并调整网络配置
- 查看关于信息
- 查看并调整个性化设置

条件

系统托盘和右侧插件区域 必须 (MUST) 正常显示和操作。
- 调节音量、网络等操作 应该 (SHOULD) 成功。
控制中心 必须 (MUST) 能够正常打开和关闭。
- 控制中心内的各个模块 应该 (SHOULD) 能够加载并显示正确信息。

6. 高级图形功能篇

在本章节的任意时刻：

如果设备已知无 OpenGL/OpenGLES/Vulkan 之中的任一图形加速
- 跳过本章节

6.1 设备节点验证

操作

查看 /dev/dri 下内容。

条件

设备 必须 (MUST) 存在 /dev/dri 目录，并存在至少一个渲染节点(render*)和至少一个设备节点(card*)。

6.2 GPU 驱动验证

操作

执行 glxinfo 和 glxgears
执行 es2_info 和 es2gears_x11
执行 eglinfo 和 eglgears_x11
执行 vkgears -info

条件

设备 应当（SHOULD） 在 es2_info 和 eglinfo 中显示硬件和驱动，不应该 (SHOULD NOT) 出现 llvmpipe 或 softpipe 字样。
设备 可能 (MAY) 在 glxinfo 和/或 vkgears -info 中显示 llvmpipe 或 softpipe 字样。
设备 可能 (MAY) 无法运行 eglgears_x11 和/或 es2gears_x11。
如果设备使用 AMD GPU:
- 设备 不应该（SHOULD NOT） 在 glxinfo 或 vkgears -info 中显示 llvmpipe 或 softpipe 字样。
- 设备 应当 (SHOULD) 能够运行 eglgears_x11 和/或 es2gears_x11。

6.3 GPU 基准测试

操作

安装 glmark2 和 glmark2-es2-x11
执行 glmark2，记录分数。
执行 glmark2-es2，记录分数。

条件

设备 应当（SHOULD） 能够运行上述程序并输出分数，不应该 (SHOULD NOT) 报错退出。
设备 应当（SHOULD） 在 glmark2-es2 中显示硬件和驱动，不应该 (SHOULD NOT) 出现 llvmpipe 或 softpipe 字样。
如果设备使用 AMD GPU:
- 设备 不应该（SHOULD NOT） 在 glmark2 中显示 llvmpipe 或 softpipe 字样。

6.3 显示管理

操作

打开“控制中心”，进入显示设置，尝试调整分辨率（若显示器支持）和刷新率（若显示器和显卡支持）。
如果设备存在其它视频输出接口：
- 接入第二台显示器，观察输出状况。
- 尝试切换多屏显示模式（复制/拓展）。
- 打开“控制中心”，进入显示设置，尝试调整第二台显示器的分辨率（若显示器支持）和刷新率（若显示器和显卡支持）。

条件

如果硬件支持，通过控制中心 应当（SHOULD） 可以正常调整所有显示输出的分辨率和刷新率。
如果设备存在其它视频输出接口：
- 两台显示器 应当（SHOULD） 支持同时输出。
- 复制/拓展显示模式 应当（SHOULD） 能够正常输出和切换。

7. deepin 内置应用篇

7.1 核心工具

操作

在启动器中打开“终端”、“文本编辑器”、“计算器”、“看图”、“画板”。
- 在文本编辑器中输入文字并尝试保存。
- 使用看图打开一张 PNG 和一张 JPG 图片。

条件

以上应用 必须 (MUST) 能够成功启动并显示主界面。
应用的核心功能（如输入、保存、打开文件）必须 (MUST) 正常工作。

7.2 系统管理

操作

打开“系统监视器”、“日志收集工具”、“设备管理器”。
在系统监视器中查看进程、资源占用情况。
在设备管理器中查看硬件列表。

条件

以上应用 必须 (MUST) 能够成功启动。
应用 应该 (SHOULD) 正确读取并显示一些系统信息
- 设备管理器 可能 (MAY) 无法显示设备的一部分信息。

7.3 影音娱乐

操作

打开“音乐”，尝试播放音乐文件夹的示例音乐。
打开“影院”，尝试播放视频文件夹的示例视频。

条件

“音乐”和“影院” 必须 (MUST) 能够启动。
音频和视频 应该 (SHOULD) 能够正常播放（允许卡顿，但声音和画面需要基本同步）。

8. 硬件加速篇

8.1 视频硬件加速解码

操作

准备若干常见码率和格式视频，如
- 1080p60_6000Kbps_h264
- 1440p60_10000Kbps_hevc
- 2160p30_20000Kbps_av1
- ......
安装 mpv，使用 mpv 播放视频。
使用系统自带视频播放器 deepin-movie 播放视频。
使用浏览器访问视频网站播放视频。

条件

硬件视频解码器支持的视频格式 必须（MUST） 成功调用硬件解码器
解码结果 必须（MUST） 软件解码结果相同
解码结果 禁止（MUST NOT） 出现颜色错误/亮度错误等问题
CPU使用率 应当（SHOULD） 在合理范围内
设备可以 可以（MAY） 不掉帧的播放视频

8.2 视频硬件加速编码

操作

使用 ffmpeg 命令尝试将一个视频文件转码为硬件支持的格式

条件

硬件视频编码器支持的视频格式 必须（MUST） 成功调用硬件编码器
编码结果 必须（MUST） 可以正常解码
CPU使用率 应当（SHOULD） 在合理范围内

9. 第一方仓库软件篇

9.1 包管理

操作

执行 sudo apt update 更新软件仓库。
执行 sudo apt install 安装任意软件包
执行 sudo apt remove 删除上一步安装的软件包
执行 sudo apt upgrade 升级软件包

条件

apt update 必须 (MUST) 成功完成，无 GPG 错误或无法连接仓库的错误。
软件包的安装和卸载 必须 (MUST) 正常工作。
apt upgrade 应该 (SHOULD) 能够正常执行，完成系统更新。

9.2 办公应用

操作

在启动器中打开 LibreOffice Writer。
- 输入一段文字并保存。
在启动器中打开 LibreOffice Calc。
- 创建一个表格并保存。
在启动器中打开 LibreOffice Impress。
- 创建一个演示文档并保存。

条件

LibreOffice 必须 (MUST) 能够启动并正常使用其核心功能。
不应该 (SHOULD NOT) 出现因缺少依赖或架构不兼容导致的启动失败。

9.3 基本构建环境

操作

执行 sudo apt install build-essential。
创建一个 hello.c 文件，内容为标准的 "Hello, World!" 程序。
执行 gcc hello.c -o hello 进行编译。
执行 ./hello 运行程序。

条件

build-essential 包 必须 (MUST) 能够被成功安装。
C 语言 "Hello, World!" 程序 必须 (MUST) 能够被成功编译和运行。

10. 外设驱动支持篇

10.1 核心外设

操作

如果设备存在 USB 接口：
- 将 USB 键盘和鼠标连接到不同的 USB 2.0/3.0 接口上。
- 将 U 盘（FAT32/EXT4/NTFS 格式）连接到 USB 接口。
- 在终端中执行 lsusb 命令。
如果设备存在 RJ45 网络接口：
- 在终端中执行 ip link 命令。
- 连接有线网络。

条件

如果设备存在 USB 接口：
- USB 键盘和鼠标 必须 (MUST) 被即时识别并正常工作。
- U 盘 必须 (MUST) 被正确识别并自动挂载，文件管理器中 应该 (SHOULD) 出现对应盘符并可访问。
- lsusb 命令 必须 (MUST) 正确显示对应设备。
如果设备存在 RJ45 网络接口：
- ip link 命令 必须 (MUST) 正确显示对应设备。
- 有线网络 必须 (MUST) 自动连接并获取 IP 地址（DHCP），能够访问互联网。

10.2 音频输出

操作

如果有 3.5mm 音频接口，插入/拔出耳机。
如果存在任何音频输出设备：
- 通过音乐播放器或浏览器播放音频或视频，确认音频输出是否正常。
如果有麦克风接口或板载麦克风：
- 使用录音测试输入。

条件

各个设备的音频输出/输入 应该 (SHOULD) 正常工作。

10.3 板载无线功能

操作

如果有板载 Wi-Fi:
- 在终端中执行 ip link 命令。
- 在控制中心搜索并连接到一个 WPA2/WPA3 加密的无线网络。
如果有板载蓝牙:
- 在控制中心尝试搜索并配对一个蓝牙设备（如蓝牙鼠标、耳机）。

条件

如果有对应设备，Wi-Fi 应该 (SHOULD) 能够扫描到网络并成功连接。
如果有对应设备，蓝牙 应该 (SHOULD) 能够开启、扫描并成功配对设备。

10.99 章节施工

此章节尚未完成，测试在此中止。

11. 第三方软件篇

此章节施工中，测试在此中止。

结论

测试日期:

测试设备型号:

测试镜像版本:

支持等级：

X.Y

摘要总结:

(简要描述测试过程中的关键发现、主要障碍和总体评价。)

测试流程

(测试报告无须写出所有步骤，若某小节所有条件均满足，则简单说明操作即可。）

未通过的最高条件:

(详细记录导致测试终止的最后一个条件，包括章节号、条件描述和实际观测现象。)

异常记录 (MAY/SHOULD):

(列出所有在测试中记录的 MAY 和被忽略的 SHOULD/SHOULD NOT 异常。)

鸣谢

在此处留下自己的 ID 表示自己参与了编辑，当该文档发布时可作为可见产出。

@YukariChiba
@Alphagocc
@apr3vau

deepin 25 正式版 DDE 移植简要指南

DDE 移植兴趣小组 — Wed, 25 Jun 2025 00:00:00 +0000

编辑的话请把自己的名字加到作者名单里

即将发布（你阅读到这个文章的时候可能已经发布了）的 deepin 25 正式版将会包含对应的新版 DDE。为了方便各个其它发行版的包维护者可以更方便的移植 DDE 到对应的发行版，这里提供一篇简要的移植指南，用以描述常见的移植问题和解决方案。

下面对项目名称的称呼均以 GitHub 对应的原始仓库名为准。

概览

相对于 deepin 25 beta，在 deepin 25 正式版中并不存在较大幅的架构调整，而是以缺陷修复以及完善之前尚未完善但计划涵盖在最终版本的组件（例如 QML 版控制中心）作为研发的重心。本阶段中有部分组件的首位版本号存在调整，另存在一些注意事项，详情请参见后续的描述。

由于这些项目的版本间互相影响，我们建议移植人员参照 deepin 25 正式版所使用的包版本进行打包，下面会对主要的部分进行详细说明。

需要注意的是，由于此文章编写时间早于版本发布时间，故最终版本镜像中使用的版本可能高于下面列出的版本。我们尽可能确保此文章的准确性，但若您需要获取 ISO 镜像中使用的确切软件版本列表，请挂载 ISO 后参阅 LIVE/FILESYS{T,0,1}.MAN/live/filesystem.manifest 路径对应的文件的内容。

主要组件

DTK 与 DTK6

DTK 是 DDE 组件与应用的基础依赖，适用于deepin 25 正式版的版本参照如下：

package	version
dtkcommon	5.7.17
dtklog	0.0.4
dtkcore	5.7.17
dtkgui	5.7.17
dtkwidget	5.7.17
dtkdeclarative	5.7.17
qt5integration	5.7.17
qt5platform-plugins	5.7.17.1
dtk6core	6.0.37
dtk6gui	6.0.37
dtk6widget	6.0.37
dtk6declarative	6.0.37
qt6integration	6.0.37
qt6platform-plugins	6.0.37

本次 DTK 组件大部分版本号以及相对应的平台插件等版本号均已对齐，例外的有 dtkcommon 与 dtklog。可参照上表进行打包。

DDE 主要组件

下面仅涉及变化较大或影响较广的组件。其余未涉及的组件可正常参照最新 tag 进行打包与移植。

下面涉及到的组件的版本参照如下：

package	version
deepin-desktop-schemas	6.0.11
dde-daemon	6.1.40
dde-session	2.0.2
dde-session-ui	6.0.30
dde-session-shell	6.0.41
dde-application-manager	1.2.31
dde-shell	2.0.1
dde-launchpad	2.0.1
dde-tray-loader	2.0.2
dde-application-wizard	0.1.15
dde-clipboard	6.1.9
deepin-service-manager	1.0.13
dde-launcher	被 dde-launchpad 取代，不再使用
dde-dock	被 dde-shell 取代，不再使用
startdde	已被废弃，不再使用

dde-application-manager

由于涉及到诸多关于应用识别的改善，故建议总是使用最新版本。

dde-session-shell

相比 beta ，此项目不涉及较大的结构调整，但你可能希望阅读 beta 时的变动描述，涉及到了仓库位置和提交历史相关的说明。

dde-shell

dde-shell 旨在将 DDE 桌面环境插件化与模块化，降低开发难度，使各个组件的替换变得更加容易，并且提供更好的桌面环境集成支持。正式阶段相比 beta 阶段集中在缺陷的修复上，并未涵盖太多的结构调整和新特性。对于 beta 以及更早版本的变化，请阅读之前的博客文章。

为保障 dde-shell 在 Qt 6.8.0 或 6.8.1 的环境可以正常运行（即使是X11环境下），若，则必须给 qtwayland 打下面的 patch：

https://codereview.qt-project.org/c/qt/qtwayland/+/603556 （此 patch 已合入 Qt 上游，涵盖在 Qt Wayland >= 6.8.2 版本中）

dde-shell 在 alpha 中为修正一个特定问题所包含的一个变更依赖另一个 Qt Wayland 的 patch：

https://github.com/deepin-community/qt6-wayland/pull/12

若你所移植的目标发行版不接受此补丁，则可考虑对 dde-shell 项目 revert 于此相关的对应 commit：

https://github.com/linuxdeepin/dde-shell/commit/77cac3d5a346728f6678eedc77fce404f0ffd8b6

dde-launchpad

dde-launchpad 现仅支持以 dde-shell 插件的形式被最终用户使用。因而，打包 dde-launchpad 现需要先打包 dde-shell，并确保用户最终使用的是 dde-shell。

dde-session

我们已在 deepin 23 beta3 起放弃了对 deepin-kwin wayland 的支持，DDE 后续所有 wayland 相关的支持均由 treeland 提供。请参见后续的 Treeland 段落。

下面涉及到的组件的版本参照如下。对于位于非 linuxdeepin 组织的软件包，此处一并给出了组织名：

package	version
vioken/waylib	0.6.13
vioken/qwlroots	0.5.3
treeland	0.5.20
ddm	0.1.10

deepin-kwin 环境

此部分相对 beta 也未存在较大变动，但由于此组件的重要性，方便起见，此处重新阐述 beta 阶段的变化：

就于此事项的详细介绍，请参见 https://github.com/orgs/linuxdeepin/discussions/11471 讨论。对于移植人员，我们建议考虑下面三种方案：

使用 Qt 6 的 deepin-kwin，放弃与上游 kwin 的共存支持。
继续使用 deepin-kwin 5.27，尽管存在一些问题，但此版本仍然可保证和上游版本 kwin 共存。
考虑打包 Treeland 环境。

Treeland 环境

Treeland 环境在 alpha -> beta 阶段无较大变化，alpha 阶段的移植注意事项仍然适用于 beta。

DDM

尽管 DDM 目前是基本功能可用状态，DDM 目前仍相对而言不够稳定。对于打包移植而言，建议采用其他DM来启动用户级的treeland。

对于其它 DM，只需要打包时安装 usr/share/wayland-sessions/treeland-user.desktop 即可。

Qt 补丁

下述假定您的发行版使用的 Qt 版本为 Qt 6.8.2。

如果你在 Treeland 下遇到小 launchpad 无法输入中文的问题，可以打下面的 patch，但是该 patch 目前尚未进行完整测试，可能存在一些问题。

https://codereview.qt-project.org/c/qt/qtbase/+/611940

另外，如果你的发行版所附的 Qt 6.8 版本并未更新至 Qt 6.8.2，则可能需要打三个额外的补丁，可参见 DDE Qt 6.8 适配说明（针对 Qt 6.8.0）以及 deepin 25 preview DDE 移植简要指南（针对 Qt 6.8.1）。

Qt 6.9 说明

DDE 尚未完整针对 Qt 6.9 进行测试，但存在一些已知问题，下面列出了对应的问题和处理方式：

QML 的 DelegateChoice/DelegateChooser 组件不存在问题

Qt 6.9 中，此组件被从 labs “转正”到了 QtQml.Models 下，相应的 import 需要修正。已知 dde-shell 存在此问题（修正相关问题的 patch）。

若有其他项目存在相同问题，则对于此问题的修正，可参考 dde-shell 的相关提交：

https://github.com/linuxdeepin/dde-shell/pull/1173

建议忽略移植的组件

deepin-anything

尽管被部分 DDE 组件依赖，但均为可选。anything 提供了内核模块，对于滚动发行版移植可能不友好，可能移植并不能得到很高的体验改善。

若忽略 deepin-anything 移植，则下列组件也应当被忽略（因为依赖了 deepin-anything）：

dde-grand-search

dde-application-wizard

获取移植帮助

如果您希望得到移植相关的帮助，请考虑加入我们 DDE 移植小组的在线交流群（下列房间有桥接，任选其一即可），一起展开相关的交流：

Matrix 群：#dde-port:deepin.org
Telegram 群：https://t.me/ddeport

deepin 25 beta DDE 移植简要指南

DDE 移植兴趣小组 — Tue, 27 May 2025 00:00:00 +0000

编辑的话请把自己的名字加到作者名单里

已经发布的 deepin 25 beta 包含了对应的新版 DDE。为了方便各个其它发行版的包维护者可以更方便的移植 DDE 到对应的发行版，这里提供一篇简要的移植指南，用以描述常见的移植问题和解决方案。

下面对项目名称的称呼均以 GitHub 对应的原始仓库名为准。

概览

相对于 deepin 25 alpha，在 deepin 25 beta 中并不存在较大幅的架构调整，而是以缺陷修复以及完善之前尚未完善但计划涵盖在最终版本的组件（例如 QML 版控制中心）作为研发的重心。需要注意的是，部分 DDE 组件在本版本中已被废弃，另外本次发布过程中也存在一个组件的 git 仓库有变动的情况，详情请参见后续的描述。

由于这些项目的版本间互相影响，我们建议移植人员参照 deepin 25 beta 所使用的包版本进行打包，下面会对主要的部分进行详细说明。

主要组件

DTK 与 DTK6

DTK 是 DDE 组件与应用的基础依赖，适用于 RC 的版本参照如下：

package	version
dtkcommon	5.7.16
dtklog	0.0.2
dtkcore	5.7.16
dtkgui	5.7.16
dtkwidget	5.7.16
dtkdeclarative	5.7.16
qt5integration	5.7.16
qt5platform-plugins	5.7.16
dtk6core	6.0.36
dtk6gui	6.0.36
dtk6widget	6.0.35
dtk6declarative	6.0.36.4
qt6integration	6.0.35
qt6platform-plugins	6.0.35

本次 DTK 组件大部分版本号以及相对应的平台插件等版本号均已对齐，例外的有 dtklog、dtk6widget、dtk6declarative、qt6integration、qt6platform-plugins。可参照上表进行打包。

DDE 主要组件

下面仅涉及变化较大或影响较广的组件。其余未涉及的组件可正常参照最新 tag 进行打包与移植。

由于 deepin 25 preview 仍在持续开发过程中，故较多组件采取了 x.99.z 的版本号策略。此外，一般情况下，此类 tag 并不会实际以 git tag 的形式存在，而只会体现在 debian/changlog 文件中。下面涉及到的此类版本号将会在版本发布前后补充对应的 git tag。

下面涉及到的组件的版本参照如下：

package	version
deepin-desktop-schemas	6.0.10
dde-daemon	6.1.32
dde-session	1.99.17
dde-application-manager	1.2.28
dde-shell	1.99.36
dde-launchpad	1.99.15
dde-tray-loader	1.99.26
dde-application-wizard	0.1.14
dde-clipboard	6.1.8
dde-launcher	被 dde-launchpad 取代，不再使用
dde-dock	被 dde-shell 取代，不再使用
startdde	已被废弃，不再使用

dde-application-manager

由于涉及到诸多关于应用识别的改善，故建议总是使用最新版本。

dde-session-shell

此项目未涉及到结构性的巨大调整，但存在仓库历史与 tag 历史变化的事项。由于项目维护需要，之前的 dde-session-shell 仓库被重命名为了 dde-session-shell-snipe，并在此后新建了名为 dde-session-shell 的仓库，这导致你无法在 dde-session-shell 仓库下找到历史（例如alpha之前）的 tag 信息。若有移植需求，可移步 dde-session-shell-snipe 仓库。

对于 beta 以及未来版本的移植，仍然保持使用 dde-session-shell 仓库即可。

dde-shell

dde-shell 旨在将 DDE 桌面环境插件化与模块化，降低开发难度，使各个组件的替换变得更加容易，并且提供更好的桌面环境集成支持。alpha 阶段相比 preview 阶段集中在缺陷的修复上，并未涵盖太多的结构调整和新特性。对于 alpha 以及更早版本的变化，请阅读之前的博客文章。

为保障 dde-shell 在 Qt 6.8.0 或 6.8.1 的环境可以正常运行（即使是X11环境下），若，则必须给 qtwayland 打下面的 patch：

https://codereview.qt-project.org/c/qt/qtwayland/+/603556 （此 patch 已合入 Qt 上游，涵盖在 Qt Wayland >= 6.8.2 版本中）

dde-shell 在 alpha 中为修正一个特定问题所包含的一个变更依赖另一个 Qt Wayland 的 patch：

https://github.com/deepin-community/qt6-wayland/pull/12

若你所移植的目标发行版不接受此补丁，则可考虑对 dde-shell 项目 revert 于此相关的对应 commit：

https://github.com/linuxdeepin/dde-shell/commit/77cac3d5a346728f6678eedc77fce404f0ffd8b6

dde-launchpad

dde-launchpad 现仅支持以 dde-shell 插件的形式被最终用户使用。因而，打包 dde-launchpad 现需要先打包 dde-shell，并确保用户最终使用的是 dde-shell。

dde-session

我们已在 deepin 23 beta3 起放弃了对 deepin-kwin wayland 的支持，DDE 后续所有 wayland 相关的支持均由 treeland 提供。请参见后续的 Treeland 段落。

下面涉及到的组件的版本参照如下。对于位于非 linuxdeepin 组织的软件包，此处一并给出了组织名：

package	version
vioken/waylib	0.6.13
vioken/qwlroots	0.5.3
treeland	0.5.20
ddm	0.1.10

deepin-kwin 环境

就于此事项的详细介绍，请参见 https://github.com/orgs/linuxdeepin/discussions/11471 讨论。对于移植人员，我们建议考虑下面两种方案：

继续使用 deepin-kwin 5.27，尽管存在一些问题，但此版本仍然可保证和上游版本 kwin 共存。
考虑打包 Treeland 环境。

Treeland 环境

Treeland 环境在 alpha -> beta 阶段无较大变化，alpha 阶段的移植注意事项仍然适用于 beta。

DDM

尽管 DDM 目前是基本功能可用状态，DDM 目前仍相对而言不够稳定。对于打包移植而言，建议采用其他DM来启动用户级的treeland。

对于其它 DM，只需要打包时安装 usr/share/wayland-sessions/treeland-user.desktop 即可。

Qt 补丁

下述假定您的发行版使用的 Qt 版本为 Qt 6.8.2。

如果你在 Treeland 下遇到小 launchpad 无法输入中文的问题，可以打下面的 patch，但是该 patch 目前尚未进行完整测试，可能存在一些问题。

https://codereview.qt-project.org/c/qt/qtbase/+/611940

Qt 6.9 说明

DDE 尚未完整针对 Qt 6.9 进行测试，但存在一些已知问题，下面列出了对应的问题和处理方式：

QML 的 DelegateChoice/DelegateChooser 组件不存在问题

Qt 6.9 中，此组件被从 labs “转正”到了 QtQml.Models 下，相应的 import 需要修正。已知 dde-control-center 与 dde-shell 存在此问题，其中 dde-control-center 已进行了修正：

https://github.com/linuxdeepin/dde-control-center/pull/2304

获取移植帮助

如果您希望得到移植相关的帮助，请考虑加入我们 DDE 移植小组的在线交流群（下列房间有桥接，任选其一即可），一起展开相关的交流：

Matrix 群：#dde-port:deepin.org
Telegram 群：https://t.me/ddeport

VSCode DevContainer 不完全食用

justforlxz — Wed, 14 May 2025 01:28:09 +0000

起因

之前已经写过一篇使用 distrobox 加速开发的文章，主要动机就是在面对不同版本的系统时，准备多份开发环境将变得十分痛苦，最终就演变成了基于 VSCode 的 Remote 开发搭配容器环境。

这样只需要准备一份 base 环境，每次只需要设置环境版本就可以安装对应的开发依赖，并且不需要更换开发工具，甚至可以在环境变量中设置好 DISPLAY 等，还能直接让容器内的程序显示在宿主环境上。

本篇文章是基于 podman 的技术方案执行的。

环境准备

安装 podman

sudo pacman -Sy podman

确认配置

cat /etc/subuid

内容应该是 lxz:100000:65536。

VSCode

打开 VScode 的设置，搜索 container，将 docker 的二进制改成 podman。

.devcontainer.json

VSCode 会识别打开目录下的 .devcontainer 目录和 .devcontainer.json 文件，本文会先介绍 json 格式的配置，之后会介绍使用 Dockerfile 构建运行环境的方式。

{
 "name": "UOS Dev Container",
 "containerUser": "root",
 "image": "uos:base",
 "customizations": {
 "vscode": {
 "extensions": [
 "llvm-vs-code-extensions.vscode-clangd",
 "donjayamanne.git-extension-pack",
 "donjayamanne.githistory",
 "theqtcompany.qt-cpp-pack",
 "eamodio.gitlens",
 "ms-vscode.cmake-tools",
 "go2sh.cmake-integration-vscode",
 "josetr.cmake-language-support-vscode",
 "VisualStudioExptTeam.vscodeintellicode",
 "VisualStudioExptTeam.intellicode-api-usage-examples",
 "esbenp.prettier-vscode",
 "ms-vscode.cpptools",
 "twxs.cmake"
 ]
 }
 },
 "runArgs": [
 "--rm",
 "--network=host",
 "--privileged",
 "--userns=host"
 ],
 "remoteEnv": {
 },
 "onCreateCommand": "apt update && apt install -y clangd-13 ninja-build curl jq && update-alternatives --install /usr/bin/clangd clangd /usr/bin/clangd-13 13 && echo > /etc/apt/sources.list",
 "postCreateCommand": "echo \"请输入系统版本：\" && read version && sh -c \"curl -s 'https://xxx/api/shuttle/repo/info?type=deb&reponame=eagle-$version' | jq -r '.data.repobase.archives[].address' | tee /etc/apt/sources.list\" && echo 'deb [trusted=yes] https://xxx/pkg/eagle-1073/release-candidate/MDQyNeeql-euoeS4u-e6v-aPkOa1izIwMjUtMDQtMjUgMTQ6NTk6MDE/ unstable main' >> /etc/apt/sources.list && apt update && apt build-dep -y . && apt install -y qt5-default qtwayland5-private-dev"
}

在 json 中，需要指定一个运行时环境，在这里使用的是本地手动准备的镜像，为了确保开发和服务器构建环境的一致，我直接使用了服务器提供的构建环境，并使用 podman image import 命令导入。

runArgs 中 --userns=host 的作用是使用主机的 user namespace，而 containerUser 必须指定成 root，因为容器内没有别的用户。

为了防止泄露内网信息，postCreateCommand 内已将域名屏蔽。

在 UOS 中，clangd 的版本有点低，需要手动创建符号，否则 VSCode 的 clangd 插件无法正常工作。这个事情就放在 onCreateCommand 中执行了，postCreateCommand 则是配置仓库和安装项目的构建依赖。

当打开项目后，VSCode 会提醒在容器内重新打开。

之后等待 VSCode 完成 server 的下载，就会开始执行 onCreateCommand 和 postCreateCommand。

启动完毕后就会开始安装插件，是一个正常的工作环境了。

打开终端，可以看到是 root 用户，但 podman 做了 uid 映射，实际目录的权限会是用户自身，不必担心。

Dockerfile

通常情况下应当使用 image，这样能确保所有人的环境是一致的，但仍然有时候想在 Dockerfile 里提前准备好一些事情，而不是在容器启动后进行配置，只需要把 image 字段改成 build。

"build": { "dockerfile": "Dockerfile" },

这种情况更推荐放在 .devcontainer 目录。在这个目录下，可以放置 Dockerfile 和其他配置文件，以便在构建容器时使用。

FROM --platform=$TARGETPLATFORM hub.deepin.com/kwin-devcontainer/linuxdeepin/eagle:base

ARG USERNAME=user
ARG UID=1000
ARG GID=1000
ARG UOS_VERSION=1073

RUN groupadd --gid $GID $USERNAME && \
 useradd --uid $UID --gid $GID -m $USERNAME

RUN apt-get update && \
 apt-get install -y \
 curl \
 jq \
 && \
 apt-get dist-upgrade -y && \
 apt-get clean && \
 rm -rf /var/lib/apt/lists/*

RUN apt-get update && \
 apt-get install -y \
 sudo \
 clangd-13 \
 apt-utils \
 apt-transport-https \
 ca-certificates \
 curl \
 gnupg \
 lsb-release \
 && \
 update-alternatives --install /usr/bin/clangd clangd /usr/bin/clangd-13 13 && \
 echo "$USERNAME ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers && \
 apt-get dist-upgrade -y && \
 apt-get clean && \
 rm -rf /var/lib/apt/lists/*

USER $USERNAME

json 也稍微修改了一下，使用 Dockerfile，并且使用参数控制一些构建过程，并且增加了本地用户。

{
 "name": "UOS Dev Container",
 "remoteUser": "lxz",
 "build": {
 "dockerfile": "Dockerfile",
 "args": {
 "UOS_VERSION": "1073",
 "USERNAME": "lxz"
 }
 },
 "customizations": {
 "vscode": {
 "extensions": [
 "llvm-vs-code-extensions.vscode-clangd",
 "donjayamanne.git-extension-pack",
 "donjayamanne.githistory",
 "theqtcompany.qt-cpp-pack",
 "eamodio.gitlens",
 "ms-vscode.cmake-tools",
 "go2sh.cmake-integration-vscode",
 "josetr.cmake-language-support-vscode",
 "VisualStudioExptTeam.vscodeintellicode",
 "VisualStudioExptTeam.intellicode-api-usage-examples",
 "esbenp.prettier-vscode",
 "saoudrizwan.claude-dev"
 ]
 }
 },
 "runArgs": [
 "--rm",
 "--network=host",
 "--privileged",
 "--env",
 "XDG_RUNTIME_DIR=${env:XDG_RUNTIME_DIR}",
 "-v",
 "${env:SSH_AUTH_SOCK}:/tmp/ssh-agent.socket",
 "-e",
 "SSH_AUTH_SOCK=/tmp/ssh-agent.socket"
 ],
 "remoteEnv": {
 "XDG_RUNTIME_DIR": "${env:XDG_RUNTIME_DIR}",
 "PODMAN_USERNS": "host"
 },
 "postCreateCommand": "sudo apt update && sudo apt build-dep -y . && sudo apt install -y qt5-default qtwayland5-private-dev"
}

https://code.visualstudio.com/docs/devcontainers/create-dev-container

resolve Maximum number of clients reached

justforlxz — Tue, 22 Apr 2025 02:00:42 +0000

最近遇到了两起 X11 下客户端报 Maximum number of clients reached 的错误，并且无法连接到 Xorg。

搜到了一个排查方法，执行

sudo ss -x src "*/tmp/.X11-unix/*" | grep -Eo "[0-9]+\s*$" | while read port
do
 sudo ss -p -x | grep -w $port | grep -v X11-unix
done | grep -Eo '".+"' | sort | uniq -c | sort -rn

这将列出每个进程及其打开的 X 连接数，按连接数降序排列。

13 "dde-session-dae"
 5 "fcitx"
 3 "kwin_x11"
 3 "kglobalaccel5"
 2 "cpis-panel-serv"
 1 "uos-activator"
 1 "startdde"

https://snapoverflow.com/ubuntu/question/4499/how-can-i-diagnose-debug-maximum-number-of-clients-reached-x-errors/

deepin 23.1 DDE 移植简要指南

DDE 移植兴趣小组 — Wed, 16 Apr 2025 00:00:00 +0000

编辑的话请把自己的名字加到作者名单里

deepin 23.1 现已发布。为了方便各个其它发行版的包维护者可以更方便的移植 DDE 到对应的发行版，这里提供一篇简要的移植指南，用以描述常见的移植问题和解决方案。

下面对项目名称的称呼均以 GitHub 对应的原始仓库名为准。 {.note}

概览

对于 DDE 本次更新并未包含大规模的结构调整，而是比较存催的缺陷修复为主的更新，对于比较值得注意的事项将会列在下方。对于 deepin 23 的注意事项，可参见 deepin 23 正式版发布时的移植指南文章所给出的说明。

由于 DDE 涉及到的各个组件项目的版本间互相影响，我们强烈建议移植人员参照 deepin 23.1 正式版所使用的包版本进行打包（也务必遵循依赖顺序打包）。下面会对主要的部分进行详细说明。

下面给出的版本号信息供打包移植时参考。若您需要获取 ISO 镜像中使用的确切软件版本列表，请挂载 ISO 后参阅 LIVE/FILESYSTEM.MANIFEST (也可能是 LIVE/FILESYS0.MAN）路径对应的文件的内容。

主要组件

DTK 与 DTK6

DTK 是 DDE 组件与应用的基础依赖，适用于 RC 的版本参照如下：

package	version
dtkcommon	5.7.5
dtklog	0.0.2
dtkcore	5.7.5
dtkgui	5.7.5
dtkwidget	5.7.5
dtkdeclarative	5.7.5
qt5integration	5.7.5
qt5platform-plugins	5.7.5
dtk6log	0.0.2
dtk6core	6.0.25
dtk6gui	6.0.25
dtk6widget	6.0.25
dtk6declarative	6.0.25
qt6integration	6.0.25
qt6platform-plugins	6.0.25

除新增的 dtklog 外，本次 DTK 版本号以及相对应的平台插件等版本号均已对齐，可直接参照打包。

deepin-kwin wayland 功能已经废弃，未来将由 treeland 替代。目前 dwayland 包已经不再使用，依赖此包的应用比如 qt5platform-plugins，不应该继续编译依赖 dwayland 的功能，可参照 linuxdeepin/developer-center#7217 打对应的 patch 规避。

目前，使用 dtk6 的正式组件有 dde-application-manager，dde-launchpad 与 dde-shell。需要注意，deepin 23 环境中 dde-shell 的托盘组件 dde-tray-loader 仍然需要使用 qt5。

DDE 主要组件

下面仅涉及变化较大或影响较广的组件。其余未涉及的组件可正常参照最新 tag 进行打包与移植。

下面涉及到的组件的版本参照如下：

package	version
deepin-osconfig	2024.08.06
dde-app-services	1.0.27
dde-session	1.2.13
dde-application-manager	1.2.27
dde-tray-loader	1.0.10
dde-shell	1.0.10
dde-launchpad	1.0.11
dde-application-wizard	0.1.10
deepin-wayland-protocols	1.10.0.28
deepin-kwin	5.27.2.213
dde-launcher	被 dde-launchpad 取代，不再使用
dde-dock	被 dde-shell 取代，不再使用

dde-application-manager

此组件现已使用主干分支最新版本（当前为 1.2.27）。请注意，较早的主干版本（例如 1.2.26）在 deepin 23 环境存在一些已知行为问题，故移植最新的 deepin 23 DDE 时，请至少使用 1.2.27 版本。

dde-session-shell

尽管此组件不存在架构性质层面的较大调整，但涉及到打包移植相关的注意事项。此组件由于主干分支的研发需求，对仓库进行过迁移到。当前 GitHub 上的 linuxdeepin/dde-session-shell 仓库历史已与之前不同。故如果你需要适用于 deepin 23 的此仓库的完整历史，请转到 dde-session-shell-snipe。所有原始仓库的提交历史以及 tag 均可在这个仓库中找到（实质是仓库重命名后新建了与原名的同名仓库）。

（注：相关请参见此邮件列表存档）

Qt 6.9 编译问题

dtk：23 版本 dtk 没有适配 qt 6.9,可尝试使用最新 tag,或者参考 Arch linux 打包提供的 patch
dde-shell：需要 https://github.com/linuxdeepin/dde-shell/pull/1091

如果遇到 qmlsc 崩溃问题，见 QTBUG-135885 和 QTBUG-135885，需要为 qtdeclarative 增加以下 patch：

https://github.com/qt/qtdeclarative/commit/d1aa2e8466bab73c3e4d120356238b482b55f02a.patch

技术预览组件

原本涉及的技术预览组件在 23 至 23.1 的这个阶段均无较大进展，故不再于此罗列。

获取移植帮助

如果您希望得到移植相关的帮助，请考虑加入我们 DDE 移植小组的在线交流群（下列房间有桥接，任选其一即可），一起展开相关的交流：

Matrix 群：#dde-port:deepin.org
Telegram 群：https://t.me/ddeport

deepin 25 alpha DDE 移植简要指南

DDE 移植兴趣小组 — Fri, 21 Mar 2025 00:00:00 +0000

编辑的话请把自己的名字加到作者名单里

即将发布（你阅读到这个文章的时候可能已经发布了）的 deepin 25 alpha 将会包含对应的新版 DDE。为了方便各个其它发行版的包维护者可以更方便的移植 DDE 到对应的发行版，这里提供一篇简要的移植指南，用以描述常见的移植问题和解决方案。

下面对项目名称的称呼均以 GitHub 对应的原始仓库名为准。 {.note}

概览

相对于 deepin 25 preview，在 deepin 25 alpha 中并不存在较大幅的架构调整，而是以缺陷修复以及完善之前尚未完善但计划涵盖在最终版本的组件（例如 QML 版控制中心）作为研发的重心。同时，我们也对 Qt、DTK 进行了更多完善，以供 DDE 组件以及 Treeland 能够更好的运行。

由于这些项目的版本间互相影响，我们建议移植人员参照 deepin 25 alpha 所使用的包版本进行打包，下面会对主要的部分进行详细说明。

主要组件

DTK 与 DTK6

DTK 是 DDE 组件与应用的基础依赖，适用于 RC 的版本参照如下：

package	version
dtkcommon	5.7.12
dtklog	0.0.2
dtkcore	5.7.12
dtkgui	5.7.12
dtkwidget	5.7.12
dtkdeclarative	5.7.12
qt5integration	5.7.12
qt5platform-plugins	5.7.7
dtk6core	6.0.32.1
dtk6gui	6.0.32
dtk6widget	6.0.32
dtk6declarative	6.0.32.1
qt6integration	6.0.32
qt6platform-plugins	6.0.32

除 dtklog 以及 dtk6 的 core 于 declarative 外，本次 DTK 版本号以及相对应的平台插件等版本号均已对齐，可直接参照打包。

DDE 主要组件

下面仅涉及变化较大或影响较广的组件。其余未涉及的组件可正常参照最新 tag 进行打包与移植。

下面涉及到的组件的版本参照如下：

package	version
dde-session	1.99.11
dde-application-manager	1.2.26
dde-shell	1.99.28
dde-launchpad	1.99.9
dde-tray-loader	1.99.19
dde-application-wizard	0.1.13
dde-clipboard	6.1.6
dde-launcher	被 dde-launchpad 取代，不再使用
dde-dock	被 dde-shell 取代，不再使用

dde-application-manager

由于涉及到诸多关于应用识别的改善，故建议总是使用最新版本。

dde-shell

为保障 dde-shell 在 Qt 6.8.0 或 6.8.1 的环境可以正常运行（即使是X11环境下），若，则必须给 qtwayland 打下面的 patch：

https://codereview.qt-project.org/c/qt/qtwayland/+/603556 （此 patch 已合入 Qt 上游，涵盖在 Qt Wayland >= 6.8.2 版本中）

另外，dde-shell 在 alpha 中为修正一个特定问题所包含的一个变更依赖另一个 Qt Wayland 的 patch：

https://github.com/deepin-community/qt6-wayland/pull/12

若你所移植的目标发行版不接受此补丁，则可考虑对 dde-shell 项目 revert 于此相关的对应 commit：

https://github.com/linuxdeepin/dde-shell/commit/77cac3d5a346728f6678eedc77fce404f0ffd8b6

dde-launchpad

dde-launchpad 现仅支持以 dde-shell 插件的形式被最终用户使用。因而，打包 dde-launchpad 现需要先打包 dde-shell，并确保用户最终使用的是 dde-shell。

dde-session

需要注意的是，我们已在 deepin 23 beta3 起放弃了对 deepin-kwin wayland 的支持，DDE 后续所有 wayland 相关的支持均由 treeland 提供。请参见后续的 Treeland 段落。

下面涉及到的组件的版本参照如下。对于位于非 linuxdeepin 组织的软件包，此处一并给出了组织名：

package	version
vioken/waylib	0.6.13
vioken/qwlroots	0.5.3
treeland	0.5.20
ddm	0.1.10

Treeland 环境

Treeland 环境相较于 deepin 23 阶段有了较多的提升，不过由于 Treeland 迭代开发过程中我们对 Qt 以及 wlroots 进行了诸多完善，故 Treeland 对 Qt 以及 wlroots 等组件有较高的版本要求，以及可能需要应用一些额外的 patch。

DDM

尽管 DDM 目前是基本功能可用状态，DDM 目前仍相对而言不够稳定。对于打包移植而言，建议采用其他DM来启动用户级的treeland。

对于其它 DM，只需要打包时安装 usr/share/wayland-sessions/treeland-user.desktop 即可。

Qt 补丁

下述假定您的发行版使用的 Qt 版本为 Qt 6.8.2。

如果你在 Treeland 下遇到小 launchpad 无法输入中文的问题，可以打下面的 patch，但是该 patch 目前尚未进行完整测试，可能存在一些问题。

https://codereview.qt-project.org/c/qt/qtbase/+/611940

获取移植帮助

如果您希望得到移植相关的帮助，请考虑加入我们 DDE 移植小组的在线交流群（下列房间有桥接，任选其一即可），一起展开相关的交流：

Matrix 群：#dde-port:deepin.org
Telegram 群：https://t.me/ddeport

deepin 25 preview DDE 移植简要指南

DDE 移植兴趣小组 — Thu, 16 Jan 2025 00:00:00 +0000

编辑的话请把自己的名字加到作者名单里

即将发布（你阅读到这个文章的时候可能已经发布了）的 deepin 25 preview 将会包含对应的新版 DDE。为了方便各个其它发行版的包维护者可以更方便的移植 DDE 到对应的发行版，这里提供一篇简要的移植指南，用以描述常见的移植问题和解决方案。

下面对项目名称的称呼均以 GitHub 对应的原始仓库名为准。 {.note}

概览

相对于 deepin 23，在 deepin 25 中，包括桌面、通知中心在内的大部分旧的 DDE 桌面组件已转化为 dde-shell 插件形式，以供更好的跨显示环境兼容性。包括控制中心在内的组件也已开始提供全新设计以及基于 QML 的全新界面。同时，我们也对 Qt、DTK 进行了更多完善，以供 DDE 组件以及 Treeland 能够更好的运行。

由于这些项目的版本间互相影响，我们建议移植人员参照 deepin 25 preview 所使用的包版本进行打包，下面会对主要的部分进行详细说明。

需要注意的是，由于此文章编写时间早于版本发布时间，故最终版本镜像中使用的版本可能高于下面列出的版本。我们尽可能确保此文章的准确性，但若您需要获取 ISO 镜像中使用的确切软件版本列表，请挂载 ISO 后参阅 LIVE/FILESYS{0,1}.MAN/live/filesystem.manifest 路径对应的文件的内容。

主要组件

DTK 与 DTK6

DTK 是 DDE 组件与应用的基础依赖，适用于 RC 的版本参照如下：

package	version
dtkcommon	5.7.7
dtklog	0.0.2
dtkcore	5.7.7
dtkgui	5.7.7
dtkwidget	5.7.7
dtkdeclarative	5.7.7
qt5integration	5.7.7
qt5platform-plugins	5.7.7
dtk6core	6.0.27
dtk6gui	6.0.27
dtk6widget	6.0.27
dtk6declarative	6.0.27
qt6integration	6.0.27
qt6platform-plugins	6.0.27

除 dtklog 外，本次 DTK 版本号以及相对应的平台插件等版本号均已对齐，可直接参照打包。

DDE 主要组件

下面仅涉及变化较大或影响较广的组件。其余未涉及的组件可正常参照最新 tag 进行打包与移植。

下面涉及到的组件的版本参照如下：

package	version
dde-session	1.99.7
dde-application-manager	1.2.23
dde-shell	1.99.19
dde-launchpad	1.99.5
dde-tray-loader	1.99.12
dde-application-wizard	0.1.11
dde-clipboard	6.1.4
dde-launcher	被 dde-launchpad 取代，不再使用
dde-dock	被 dde-shell 取代，不再使用

dde-application-manager

由于涉及到诸多关于应用识别的改善，故建议总是使用最新版本。

dde-shell

dde-shell 旨在将 DDE 桌面环境插件化与模块化，降低开发难度，使各个组件的替换变得更加容易，并且提供更好的桌面环境集成支持。preview 阶段，dde-shell 已经可以满足原计划的部分目标。现 DDE 环境下，dde-shell 已取代 dde-dock 来负责管理整个 dock 区域、 dde-launchpad 提供了对应的 dde-shell 插件用以展示启动器相关的界面、原 dde-session-ui 中的通知中心部分也转到了 dde-shell 中，且转用了新的界面设计。

关于 shell 的服务启动方面，为了方便故障排查，dde-shell 从原本的单进程转为了两个进程（分别提供桌面和任务栏两个部分）。另外，shell项目的任务栏部分在此阶段也配合 dde-application-manager 对应用识别的准确度进行了诸多完善。若仍有发现应用错误识别和错误分组的问题，欢迎及时反馈。

为保障dde-shell在Qt6.8之后的环境可以正常运行（即使是X11环境下），必须给qtwayland打下面的patch：

https://codereview.qt-project.org/c/qt/qtwayland/+/603556

dde-launchpad

dde-launchpad 现仅支持以 dde-shell 插件的形式被最终用户使用。因而，打包 dde-launchpad 现需要先打包 dde-shell，并确保用户最终使用的是 dde-shell。

dde-session

下面涉及到的组件的版本参照如下。对于位于非 linuxdeepin 组织的软件包，此处一并给出了组织名：

package	version
vioken/waylib	0.6.10
vioken/qwlroots	0.5.2
treeland	0.5.17
ddm	0.1.9

Treeland 环境

DDM

尽管 DDM 目前是基本功能可用状态，DDM 目前仍相对而言不够稳定。对于打包移植而言，建议采用其他DM来启动用户级的treeland。

对于其它 DM，只需要打包时安装 usr/share/wayland-sessions/treeland-user.desktop 即可。

Qt 补丁

下述假定您的发行版使用的 Qt 版本为 Qt 6.8.1。

为保障 dde-shell 在 Treeland 上可以正常运行，需要打下面的 patch，否则可能会出现 dde-shell 崩溃的情况。

https://codereview.qt-project.org/c/qt/qtbase/+/607654

如果你在 Treeland 下遇到小 launchpad 无法输入中文的问题，可以打下面的 patch，但是该 patch 目前尚未进行完整测试，可能存在一些问题。

https://codereview.qt-project.org/c/qt/qtbase/+/611940

另外，如果你的发行版所附的 Qt 6.8 版本并未更新至 Qt 6.8.1，则可能需要打两个额外的补丁，可参见 DDE Qt 6.8 适配说明。

获取移植帮助

如果您希望得到移植相关的帮助，请考虑加入我们 DDE 移植小组的在线交流群（下列房间有桥接，任选其一即可），一起展开相关的交流：

Matrix 群：#dde-port:deepin.org
Telegram 群：https://t.me/ddeport

使用 distrobox 和 nix 加速 UOS 开发

justforlxz — Thu, 02 Jan 2025 08:18:00 +0000

UOS 这仓库有多鬼畜，就不用我多说了，开发的时候每次都要重装一个不同版本的系统也挺麻烦，比如 1060、1063、1070、1070u1。。。

所以我就想到，我可以用构建用的 rootfs 加上仓库，整出来一个基础环境，然后通过 distrobox 来启动，这样随时都可以快速准备一个环境。

平时我用的开发工具就 neovim 和 vscode 居多，所以再配合上 nix 把 neovim 和一些 UOS 缺少的工具都装上，想想都是美滋滋。

说干就干!

构建 Docker 镜像

由于 UOS 有多个不同架构的支持，肯定不能绑死到一个平台上，我使用 docker buildx 来构建多架构镜像。rootfs 我就不公开了，直接上 Dockerfile。

FROM --platform=$TARGETPLATFORM scratch

ARG TARGETARCH
ARG UOS_VERSION

ADD buster-${TARGETARCH}-1050update4.tgz /

RUN echo "deb [trusted=yes] http://pools.uniontech.com/desktop-professional ${UOS_VERSION:-eagle/1070} main contrib non-free" > /etc/apt/sources.list

RUN apt-get update && apt-get install -y \
 apt-utils \
 apt-transport-https \
 ca-certificates \
 curl \
 gnupg \
 lsb-release \
 && apt-get dist-upgrade -y \
 && apt-get clean \
 && rm -rf /var/lib/apt/lists/*

CMD [ "bash" ]

这里为了方便我构建，我将仓库的名称使用变量控制了。

docker buildx build --platform=linux/amd64 -t linuxdeepin/1063:base --build-arg UOS_VERSION=eagle/1063 . --load

只需要控制 label 和仓库名称，就能快速的创建出一个可用的 docker 镜像。使用 --load 参数构建完以后直接导入镜像，可以在 docker images 中看到。

创建 Distrobox 环境

现在有个可用的 docker 镜像，就可以使用 distrobox 创建环境了。

distrobox create --image linuxdeepin/1063:base --name 1063 --volume /nix:/nix:rw --additional-flags "--pids-limit -1"

安装 nix 的过程请参考上一篇文章，这里是把 nix 挂载到环境里了。

运行以后等待一会儿，就看到创建成功了。

Creating '1063' using image linuxdeepin/1063:base [ OK ]
Distrobox '1063' successfully created.
To enter, run:

distrobox enter 1063

Successfully copied 2.05kB to /tmp/1063.os-release

提醒我们用 distrobox enter 1063 进入环境。

运行

运行的话没啥问题，只是需要设置一下用户密码，不知道是不是 distrobox 改变策略了，以前应该是首次进入的时候就提醒设置密码，现在必须手动先运行一下 passwd，不然 sudo 之类的命令是不能用的。

❯ distrobox enter 1063
Starting container... [ OK ]
Installing basic packages... [ OK ]
Setting up devpts mounts... [ OK ]
Setting up read-only mounts... [ OK ]
Setting up read-write mounts... [ OK ]
Setting up host's sockets integration... [ OK ]
Integrating host's themes, icons, fonts... [ OK ]
Setting up distrobox profile... [ OK ]
Setting up sudo... [ OK ]
Setting up user groups... [ OK ]
Setting up user's group list... [ OK ]
Adding user... [ OK ]
Ensuring user's access... [ OK ]

Container Setup Complete!

Treeland Part.1 如何实现一个基于 wlroots 的合成器

justforlxz — Sat, 09 Nov 2024 04:00:00 +0000

名词概念

Qt

Qt（/ˈkjuːt/，发音同“cute”）是一个跨平台的C++应用程序开发框架。广泛用于开发GUI程序，这种情况下又被称为部件工具箱。也可用于开发非GUI程序，例如控制台工具和服务器。

wlroots

用于构建 Wayland 合成器的模块化工具集，简化了约 60,000 行代码的开发工作。

提供抽象底层显示和输入的后端，支持 KMS/DRM、libinput、Wayland、X11 等，可动态创建和销毁。
实现多种 Wayland 接口，支持协议扩展，促进合成器标准化。
提供通用合成器组件，如物理空间输出管理。
集成 Xwayland 抽象，简化 X11 窗口管理。
提供渲染器抽象，支持简单和自定义渲染需求。

seat

由分配给特定工作场景的所有硬件设备组成。它至少包含一个图形设备，通常还有键盘和鼠标。此外，它可能包括摄像头、声卡等设备。座位由座位名称标识，这是一个短字符串（不超过64个字符），以”seat”四个字符开头，后跟至少一个a-zA-Z0-9范围内的字符，或”_”和”-“。这种命名方式适合用于文件名。座位名称可能是稳定的，也可能不稳定，如果座位再次可用，其名称可以重复使用。

RHI

RHI 是 Renderer Hardware Interface（渲染硬件接口）的缩写，是一套对硬件的抽象，在上层只需要设置参数，底层具体使用的是 OpenGL、Vulkan、DX12 还是 Metal 哪套接口，我们是不必关心的。

Qt6 提供了 QRHI，为 Qt 程序提供了底层的硬件抽象，这样上层的 QtQuick 组件在执行 GPU 渲染时，就可以自动调用对应的驱动接口。

QPA

Qt 平台抽象（QPA）是 Qt 中的核心平台抽象层。

QPA 的 API 可通过类前缀”QPlatform*”识别，用于实现 Qt GUI 中的高级类。例如，QPlatformWindow 用于窗口系统集成，而 QPlatformTheme 和 QStyleHint 则用于深层次的平台主题和集成。

基本工作流程

Treeland 使用 QQuickWindow 作为渲染的根，这样在 Treeland 里开发时，就如同开发一个普通 Qt 程序一样，先创建一个 Window，在 Window 内创建 Qt 控件，使用 QEvent 处理各种事件。

那么 Treeland 是如何实现这件事的呢？

QQuickWindow 的私有类提供了自定义 QQuickGraphicsDevice 对象的接口，而 QQuickGraphicsDevice 可以使用 fromOpenGLContext 和 fromPhyicalDevice 创建新的对象，那么 Treeland 只需要继承 QQuickWindow，并从 wlroots 获取 OpenGL context 和 phyical device，就可以将 Qt QuickWindow 的渲染，嫁接到 wlroots 上。

通过将 wlroots 的渲染上下文与 Qt 的渲染上下文进行结合，可以将 wlroots 渲染的图形结果嵌入到 Qt 应用程序的渲染流程中，可以直接使用 wlroots 提供的图形资源和设备对象，如物理设备（phdev）、逻辑设备（dev）和队列族（queue_family），以减少不必要的上下文切换和资源拷贝。这样，Qt 就可以利用 wlroots 提供的渲染能力，同时能够继续使用 Qt 的渲染框架和 API。

之后在 Qt QPA 中将屏幕信息，以及输入信息转换成 Qt 内部对象，从而利用 Qt 自身的事件循环等机制继续处理。

Qt QPA

QPA 为 Qt 提供了跨平台的接口抽象能力，我们可以提供自己的 QPA 插件来为 Qt 程序提供新的能力，例如将 wlroots 的输入事件转换成 Qt 内部事件。

输入事件处理

Treeland 处理底层事件与上层事件的流程

bool WOutputRenderWindow::event(QEvent *event)
{
 Q_D(WOutputRenderWindow);

 if (event->type() == doRenderEventType) {
 QCoreApplication::removePostedEvents(this, doRenderEventType);
 d_func()->doRender();
 return true;
 }

 if (QW::RenderWindow::beforeDisposeEventFilter(this, event)) {
 event->accept();
 QW::RenderWindow::afterDisposeEventFilter(this, event);
 return true;
 }

 bool isAccepted = QQuickWindow::event(event);
 if (QW::RenderWindow::afterDisposeEventFilter(this, event))
 return true;

 return isAccepted;
}

在 WOutputRenderWindow 的事件处理中，会额外调用下 seat 的事件过滤器，确保合成器可以拦截掉一部分事件，例如将一部分按键拦截下来，不发送给客户端。

bool QWlrootsRenderWindow::beforeDisposeEventFilter(QEvent *event)
{
 if (event->isInputEvent()) {
 auto ie = static_cast<QInputEvent*>(event);
 auto device = WInputDevice::from(ie->device());
 Q_ASSERT(device);
 Q_ASSERT(device->seat());
 lastActiveCursor = device->seat()->cursor();
 return device->seat()->filterEventBeforeDisposeStage(window(), ie);
 }

 return false;
}

这段代码展示了转换输入设备的功能，判断输入设备的类型，创建对应的 QInputDevice 对象。

QPointer<QInputDevice> QWlrootsIntegration::addInputDevice(WInputDevice *device, const QString &seatName)
{
 QPointer<QInputDevice> qtdev;
 auto qwDevice = device->handle();
 const QString name = QString::fromUtf8(qwDevice->handle()->name);
 qint64 systemId = reinterpret_cast<qint64>(device);

 switch (qwDevice->handle()->type) {
 case WLR_INPUT_DEVICE_KEYBOARD: {
 qtdev = new QInputDevice(name, systemId, QInputDevice::DeviceType::Keyboard, seatName);
 break;
 }
 case WLR_INPUT_DEVICE_POINTER: {
 qtdev = new QPointingDevice(name, systemId, QInputDevice::DeviceType::TouchPad, QPointingDevice::PointerType::Generic,
 QInputDevice::Capability::Position | QInputDevice::Capability::Hover
 | QInputDevice::Capability::Scroll | QInputDevice::Capability::MouseEmulation,
 10, 32, seatName, QPointingDeviceUniqueId());
 break;
 }
 case WLR_INPUT_DEVICE_TOUCH: {
 qtdev = new QPointingDevice(name, systemId, QInputDevice::DeviceType::TouchScreen, QPointingDevice::PointerType::Finger,
 QInputDevice::Capability::Position | QInputDevice::Capability::Area | QInputDevice::Capability::MouseEmulation,
 10, 32, seatName, QPointingDeviceUniqueId());
 break;
 }
 case WLR_INPUT_DEVICE_TABLET_TOOL: {
 qtdev = new QPointingDevice(name, systemId, QInputDevice::DeviceType::Stylus, QPointingDevice::PointerType::Pen,
 QInputDevice::Capability::XTilt | QInputDevice::Capability::YTilt | QInputDevice::Capability::Pressure,
 1, 32, seatName, QPointingDeviceUniqueId());
 break;
 }
 case WLR_INPUT_DEVICE_TABLET_PAD: {
 auto pad = wlr_tablet_pad_from_input_device(qwDevice->handle());
 qtdev = new QPointingDevice(name, systemId, QInputDevice::DeviceType::TouchPad, QPointingDevice::PointerType::Pen,
 QInputDevice::Capability::Position | QInputDevice::Capability::Hover | QInputDevice::Capability::Pressure,
 1, pad->button_count, seatName, QPointingDeviceUniqueId());
 break;
 }
 case WLR_INPUT_DEVICE_SWITCH: {
 qtdev = new QInputDevice(name, systemId, QInputDevice::DeviceType::Keyboard, seatName);
 break;
 }
 }

 if (qtdev) {
 device->setQtDevice(qtdev);
 QWindowSystemInterface::registerInputDevice(qtdev);

 if (qtdev->type() == QInputDevice::DeviceType::Mouse || qtdev->type() == QInputDevice::DeviceType::TouchPad) {
 auto primaryQtDevice = QPointingDevice::primaryPointingDevice();
 if (!WInputDevice::from(primaryQtDevice)) {
 // Ensure the primary pointing device is the WInputDevice
 auto pd = const_cast<QPointingDevice*>(primaryQtDevice);
 pd->setParent(nullptr);
 delete pd;
 }
 Q_ASSERT(WInputDevice::from(QPointingDevice::primaryPointingDevice()));
 } else if (qtdev->type() == QInputDevice::DeviceType::Keyboard) {
 auto primaryQtDevice = QInputDevice::primaryKeyboard();
 if (!WInputDevice::from(primaryQtDevice)) {
 // Ensure the primary keyboard device is the WInputDevice
 auto pd = const_cast<QInputDevice*>(primaryQtDevice);
 pd->setParent(nullptr);
 delete pd;
 }
 Q_ASSERT(WInputDevice::from(QInputDevice::primaryKeyboard()));
 }
 }

 return qtdev;
}

客户端事件

在 Treeland 还有一种事件需要处理，当用户点击一个窗口，合成器需要告知客户端哪个坐标点击了。或者使用键盘进行输入时，需要告知客户端输入的内容。

首先，Treeland 会标记一个窗口成为激活窗口，设置给 seat，这样 wlroots 就知道哪个窗口此时拥有焦点。

之后当键盘发生输入事件时，Treeland 没有过滤掉按键事件，或者是放行某些按键，这些剩余的输入事件就会在 wseat 的 sendEvent 中，发送给激活的客户端。

// for keyboard event
inline bool doNotifyKey(WInputDevice *device, uint32_t keycode, uint32_t state, uint32_t timestamp) {
 if (!keyboardFocusSurface())
 return false;

 q_func()->setKeyboard(device);
 /* Send modifiers to the client. */
 this->handle()->keyboard_notify_key(timestamp, keycode, state);
 return true;
}

屏幕信息

在 QPA 中还对 WOutput 进行了封装 QWlrootsScreen。

QWlrootsScreen *QWlrootsIntegration::addScreen(WOutput *output)
{
 m_screens << new QWlrootsScreen(output);

 if (isMaster()) {
 QWindowSystemInterface::handleScreenAdded(m_screens.last());

 if (m_placeholderScreen) {
 QWindowSystemInterface::handleScreenRemoved(m_placeholderScreen.release());
 }
 } else {
 Q_UNUSED(new QScreen(m_screens.last()))
 }

 m_screens.last()->initialize();
 output->setScreen(m_screens.last());

 return m_screens.last();
}

QWlrootsScreen 继承自 QPlatformScreen，做的事情是将部分参数进行转换，例如physicalSize、devicePixelRatio、DPI等，之后通过 QWindowSystemInterface::handleScreenAdded 将创建好的 QWlrootsScreen 添加进 Qt 内。

Qt RHI

摘抄一段来自 waylib 中初始化 Qt RHI 的代码

bool WOutputRenderWindowPrivate::initRCWithRhi()
{
 W_Q(WOutputRenderWindow);

 QQuickRenderControlPrivate *rcd = QQuickRenderControlPrivate::get(rc());
 QSGRhiSupport *rhiSupport = QSGRhiSupport::instance();

// sanity check for Vulkan
#ifdef ENABLE_VULKAN_RENDER
 if (rhiSupport->rhiBackend() == QRhi::Vulkan) {
 vkInstance.reset(new QVulkanInstance());

 auto phdev = wlr_vk_renderer_get_physical_device(m_renderer->handle());
 auto dev = wlr_vk_renderer_get_device(m_renderer->handle());
 auto queue_family = wlr_vk_renderer_get_queue_family(m_renderer->handle());

#if QT_VERSION > QT_VERSION_CHECK(6, 6, 0)
 auto instance = wlr_vk_renderer_get_instance(m_renderer->handle());
 vkInstance->setVkInstance(instance);
#endif
 // vkInstance->setExtensions(fromCStyleList(vkRendererAttribs.extension_count, vkRendererAttribs.extensions));
 // vkInstance->setLayers(fromCStyleList(vkRendererAttribs.layer_count, vkRendererAttribs.layers));
 vkInstance->setApiVersion({1, 1, 0});
 vkInstance->create();
 q->setVulkanInstance(vkInstance.data());

 auto gd = QQuickGraphicsDevice::fromDeviceObjects(phdev, dev, queue_family);
 q->setGraphicsDevice(gd);
 } else
#endif
 if (rhiSupport->rhiBackend() == QRhi::OpenGLES2) {
 Q_ASSERT(wlr_renderer_is_gles2(m_renderer->handle()));
 auto egl = wlr_gles2_renderer_get_egl(m_renderer->handle());
 auto display = wlr_egl_get_display(egl);
 auto context = wlr_egl_get_context(egl);

 this->glContext = new QW::OpenGLContext(display, context, rc());
 bool ok = this->glContext->create();
 if (!ok)
 return false;

 q->setGraphicsDevice(QQuickGraphicsDevice::fromOpenGLContext(this->glContext));
 } else {
 return false;
 }

 QOffscreenSurface *offscreenSurface = new QW::OffscreenSurface(nullptr, q);
 offscreenSurface->create();

 QSGRhiSupport::RhiCreateResult result = rhiSupport->createRhi(q, offscreenSurface);
 if (!result.rhi) {
 qWarning("WOutput::initRhi: Failed to initialize QRhi");
 return false;
 }

 rcd->rhi = result.rhi;
 // Ensure the QQuickRenderControl don't reinit the RHI
 rcd->ownRhi = true;
 if (!rc()->initialize())
 return false;
 rcd->ownRhi = result.own;
 Q_ASSERT(rcd->rhi == result.rhi);
 Q_ASSERT(!swapchain);

 return true;
}

先获取 QSGRhiSupport 及相关控制对象。

判断 RHI backend 的类型，需要适配 vulkan、gles等。

从 wlroots 获取物理设备等参数，使用 QQuickGraphicsDevice::fromDeviceObjects 创建 Qt 的 QQuickGraphicsDevice。

render window的私有类是继承自 QQuickWindowPrivate，只需要将获取到的 QQuickGraphicsDevice 设置给 QQuickWindowPrivate::setGraphicsDevice 即可。

之后创建一个离屏渲染表面，用于 RHI 的初始化。

Qt Viewport

在 Qt 中，想要查看或者渲染一个组件，需要使用 Viewport 组件，俗称照相机。

视口（Viewport）是一个可观察的多边形区域，只有 Viewport 范围内的画面才能显示到屏幕上。

wlroots 中的 Viewport 是一个与 Wayland 显示协议相关的概念，主要用于定义渲染输出在屏幕上的显示区域。它允许在渲染时对显示内容进行缩放、裁剪或平移，以适应不同的分辨率和显示需求。

Treeland 使用 WOutputViewport 提供 Viewport 功能，使用 wlroots 的 wlr_output 中的屏幕信息，对画面进行矩阵变换，这里会涉及到屏幕的缩放、DPI等参数。

QMatrix4x4 WOutputViewport::renderMatrix() const
{
 QMatrix4x4 renderMatrix;

 if (auto customTransform = viewportTransform()) {
 customTransform->applyTo(&renderMatrix);
 } else if (parentItem() && !ignoreViewport() && input() != this) {
 auto d = QQuickItemPrivate::get(const_cast<WOutputViewport*>(this));
 auto viewportMatrix = d->itemNode()->matrix().inverted();
 if (auto inputItem = input()) {
 QMatrix4x4 matrix = QQuickItemPrivate::get(parentItem())->itemToWindowTransform();
 matrix *= QQuickItemPrivate::get(inputItem)->windowToItemTransform();
 renderMatrix = viewportMatrix * matrix.inverted();
 } else { // the input item is window's contentItem
 auto pd = QQuickItemPrivate::get(parentItem());
 QMatrix4x4 parentMatrix = pd->itemToWindowTransform().inverted();
 renderMatrix = viewportMatrix * parentMatrix;
 }
 }

 return renderMatrix;
}

WOutputViewport 提供了 Viewport 所需的所有参数，变换矩阵、源几何大小、目标几何大小等信息。

在 WOutputRenderWindow 的事件中，判断如果是渲染的事件，就执行渲染。

bool WOutputRenderWindow::event(QEvent *event)
{
 Q_D(WOutputRenderWindow);

 if (event->type() == doRenderEventType) {
 QCoreApplication::removePostedEvents(this, doRenderEventType);
 d_func()->doRender();
 return true;
 }

 if (QW::RenderWindow::beforeDisposeEventFilter(this, event)) {
 event->accept();
 QW::RenderWindow::afterDisposeEventFilter(this, event);
 return true;
 }

 bool isAccepted = QQuickWindow::event(event);
 if (QW::RenderWindow::afterDisposeEventFilter(this, event))
 return true;

 return isAccepted;
}

在 doRender 中，遍历所有的 Output，执行 beginRender，然后执行 Output 的渲染。

void WOutputRenderWindowPrivate::doRender(const QList<OutputHelper *> &outputs,
 bool forceRender, bool doCommit)
{
 Q_ASSERT(rendererList.isEmpty());
 Q_ASSERT(!inRendering);
 inRendering = true;

 W_Q(WOutputRenderWindow);
 for (OutputLayer *layer : std::as_const(layers)) {
 layer->beforeRender(q);
 }

 rc()->polishItems();

 if (QSGRendererInterface::isApiRhiBased(WRenderHelper::getGraphicsApi()))
 rc()->beginFrame();
 rc()->sync();

 QQuickAnimatorController_advance(animationController.get());
 Q_EMIT q->beforeRendering();
 runAndClearJobs(&beforeRenderingJobs);

 auto needsCommit = doRenderOutputs(outputs, forceRender);

 Q_EMIT q->afterRendering();
 runAndClearJobs(&afterRenderingJobs);

 if (QSGRendererInterface::isApiRhiBased(WRenderHelper::getGraphicsApi()))
 rc()->endFrame();

 if (doCommit) {
 for (auto i : std::as_const(needsCommit)) {
 bool ok = i.first->commit(i.second);

 if (i.second->currentBuffer()) {
 i.second->endRender();
 }

 i.first->resetState(ok);
 }
 }

 resetGlState();

 // On Intel&Nvidia multi-GPU environment, wlroots using Intel card do render for all
 // outputs, and blit nvidia's output buffer in drm_connector_state_update_primary_fb,
 // the 'blit' behavior will make EGL context to Nvidia renderer. So must done current
 // OpenGL context here in order to ensure QtQuick always make EGL context to Intel
 // renderer before next frame.
 if (glContext)
 glContext->doneCurrent();

 inRendering = false;
 Q_EMIT q->renderEnd();
}

qw_buffer *WBufferRenderer::beginRender(const QSize &pixelSize, qreal devicePixelRatio,
 uint32_t format, RenderFlags flags)
{
 Q_ASSERT(!state.buffer);
 Q_ASSERT(m_output);

 if (pixelSize.isEmpty())
 return nullptr;

 Q_EMIT beforeRendering();

 m_damageRing.set_bounds(pixelSize.width(), pixelSize.height());

 // configure swapchain
 if (flags.testFlag(RenderFlag::DontConfigureSwapchain)) {
 auto renderFormat = pickFormat(m_output->renderer(), format);
 if (!renderFormat) {
 qWarning("wlr_renderer doesn't support format 0x%s", drmGetFormatName(format));
 return nullptr;
 }

 if (!m_swapchain || QSize(m_swapchain->handle()->width, m_swapchain->handle()->height) != pixelSize
 || m_swapchain->handle()->format.format != renderFormat->format) {
 if (m_swapchain)
 delete m_swapchain;
 m_swapchain = qw_swapchain::create(m_output->allocator()->handle(), pixelSize.width(), pixelSize.height(), renderFormat);
 }
 } else if (flags.testFlag(RenderFlag::UseCursorFormats)) {
 bool ok = m_output->configureCursorSwapchain(pixelSize, format, &m_swapchain);
 if (!ok)
 return nullptr;
 } else {
 bool ok = m_output->configurePrimarySwapchain(pixelSize, format, &m_swapchain,
 !flags.testFlag(DontTestSwapchain));
 if (!ok)
 return nullptr;
 }

 // TODO: Support scanout buffer of wlr_surface(from WSurfaceItem)
 int bufferAge;
 auto wbuffer = m_swapchain->acquire(&bufferAge);
 if (!wbuffer)
 return nullptr;
 auto buffer = qw_buffer::from(wbuffer);

 if (!m_renderHelper)
 m_renderHelper = new WRenderHelper(m_output->renderer());
 m_renderHelper->setSize(pixelSize);

 auto wd = QQuickWindowPrivate::get(window());
 Q_ASSERT(wd->renderControl);
 auto lastRT = m_renderHelper->lastRenderTarget();
 auto rt = m_renderHelper->acquireRenderTarget(wd->renderControl, buffer);
 if (rt.isNull()) {
 buffer->unlock();
 return nullptr;
 }

 auto rtd = QQuickRenderTargetPrivate::get(&rt);
 QSGRenderTarget sgRT;

 if (rtd->type == QQuickRenderTargetPrivate::Type::PaintDevice) {
 sgRT.paintDevice = rtd->u.paintDevice;
 } else {
 Q_ASSERT(rtd->type == QQuickRenderTargetPrivate::Type::RhiRenderTarget);
 sgRT.rt = rtd->u.rhiRt;
 sgRT.cb = wd->redirect.commandBuffer;
 Q_ASSERT(sgRT.cb);
 sgRT.rpDesc = rtd->u.rhiRt->renderPassDescriptor();

#ifndef QT_NO_OPENGL
 if (wd->rhi->backend() == QRhi::OpenGLES2) {
 auto glRT = QRHI_RES(QGles2TextureRenderTarget, rtd->u.rhiRt);
 Q_ASSERT(glRT->framebuffer >= 0);
 auto glContext = QOpenGLContext::currentContext();
 Q_ASSERT(glContext);
 QOpenGLContextPrivate::get(glContext)->defaultFboRedirect = glRT->framebuffer;
 }
#endif
 }

 state.flags = flags;
 state.context = wd->context;
 state.pixelSize = pixelSize;
 state.devicePixelRatio = devicePixelRatio;
 state.bufferAge = bufferAge;
 state.lastRT = lastRT;
 state.buffer = buffer;
 state.renderTarget = rt;
 state.sgRenderTarget = sgRT;

 return buffer;
}

QVector<std::pair<OutputHelper*, WBufferRenderer*>>
WOutputRenderWindowPrivate::doRenderOutputs(const QList<OutputHelper*> &outputs, bool forceRender)
{
 QVector<OutputHelper*> renderResults;
 renderResults.reserve(outputs.size());
 for (OutputHelper *helper : std::as_const(outputs)) {
 if (Q_LIKELY(!forceRender)) {
 if (!helper->renderable()
 || Q_UNLIKELY(!WOutputViewportPrivate::get(helper->output())->renderable())
 || !helper->output()->output()->isEnabled())
 continue;

 if (!helper->contentIsDirty()) {
 if (helper->needsFrame())
 renderResults.append(helper);
 continue;
 }
 }

 Q_ASSERT(helper->output()->output()->scale() <= helper->output()->devicePixelRatio());

 const auto &format = helper->qwoutput()->handle()->render_format;
 const auto renderMatrix = helper->output()->renderMatrix();

 // maybe using the other WOutputViewport's QSGTextureProvider
 if (!helper->output()->depends().isEmpty())
 updateDirtyNodes();

 qw_buffer *buffer = helper->beginRender(helper->bufferRenderer(), helper->output()->output()->size(), format,
 WBufferRenderer::RedirectOpenGLContextDefaultFrameBufferObject);
 Q_ASSERT(buffer == helper->bufferRenderer()->currentBuffer());
 if (buffer) {
 helper->render(helper->bufferRenderer(), 0, renderMatrix,
 helper->output()->effectiveSourceRect(),
 helper->output()->targetRect(),
 helper->output()->preserveColorContents());
 }
 renderResults.append(helper);
 }

 QVector<std::pair<OutputHelper*, WBufferRenderer*>> needsCommit;
 needsCommit.reserve(renderResults.size());
 for (auto helper : std::as_const(renderResults)) {
 auto bufferRenderer = helper->afterRender();
 if (bufferRenderer)
 needsCommit.append({helper, bufferRenderer});
 }

 rendererList.clear();

 return needsCommit;
}

void WBufferRenderer::render(int sourceIndex, const QMatrix4x4 &renderMatrix,
 const QRectF &sourceRect, const QRectF &targetRect,
 bool preserveColorContents)
{
 Q_ASSERT(state.buffer);

 const auto &source = m_sourceList.at(sourceIndex);
 QSGRenderer *renderer = ensureRenderer(sourceIndex, state.context);
 auto wd = QQuickWindowPrivate::get(window());

 const qreal devicePixelRatio = state.devicePixelRatio;
 state.renderer = renderer;
 state.worldTransform = renderMatrix;
 renderer->setDevicePixelRatio(devicePixelRatio);
 renderer->setDeviceRect(QRect(QPoint(0, 0), state.pixelSize));
 renderer->setRenderTarget(state.sgRenderTarget);
 const auto viewportRect = scaleToRect(targetRect, devicePixelRatio);

 auto softwareRenderer = dynamic_cast<QSGSoftwareRenderer*>(renderer);
 { // before render
 if (softwareRenderer) {
 // because software renderer don't supports viewportRect,
 // so use transform to simulation.
 const auto mapTransform = inputMapToOutput(sourceRect, targetRect,
 state.pixelSize, state.devicePixelRatio);
 if (!mapTransform.isIdentity())
 state.worldTransform = mapTransform * state.worldTransform;
 state.worldTransform.optimize();
 auto image = getImageFrom(state.renderTarget);
 image->setDevicePixelRatio(devicePixelRatio);

 // TODO: Should set to QSGSoftwareRenderer, but it's not support specify matrix.
 // If transform is changed, it will full repaint.
 if (isRootItem(source.source)) {
 auto rootTransform = QQuickItemPrivate::get(wd->contentItem)->itemNode();
 if (rootTransform->matrix() != state.worldTransform)
 rootTransform->setMatrix(state.worldTransform);
 } else {
 auto t = state.worldTransform.toTransform();
 if (t.type() > QTransform::TxTranslate) {
 (image->operator QImage &()).fill(renderer->clearColor());
 softwareRenderer->markDirty();
 }

 applyTransform(softwareRenderer, t);
 }
 } else {
 state.worldTransform.optimize();

 bool flipY = wd->rhi ? !wd->rhi->isYUpInNDC() : false;
 if (state.renderTarget.mirrorVertically())
 flipY = !flipY;

 if (viewportRect.isValid()) {
 QRect vr = viewportRect;
 if (flipY)
 vr.moveTop(-vr.y() + state.pixelSize.height() - vr.height());
 renderer->setViewportRect(vr);
 } else {
 renderer->setViewportRect(QRect(QPoint(0, 0), state.pixelSize));
 }

 QRectF rect = sourceRect;
 if (!rect.isValid())
 rect = QRectF(QPointF(0, 0), QSizeF(state.pixelSize) / devicePixelRatio);

 const float left = rect.x();
 const float right = rect.x() + rect.width();
 float bottom = rect.y() + rect.height();
 float top = rect.y();

 if (flipY)
 std::swap(top, bottom);

 QMatrix4x4 matrix;
 matrix.ortho(left, right, bottom, top, 1, -1);

 QMatrix4x4 projectionMatrix, projectionMatrixWithNativeNDC;
 projectionMatrix = matrix * state.worldTransform;

 if (wd->rhi && !wd->rhi->isYUpInNDC()) {
 std::swap(top, bottom);

 matrix.setToIdentity();
 matrix.ortho(left, right, bottom, top, 1, -1);
 }
 projectionMatrixWithNativeNDC = matrix * state.worldTransform;

 renderer->setProjectionMatrix(projectionMatrix);
 renderer->setProjectionMatrixWithNativeNDC(projectionMatrixWithNativeNDC);

 auto textureRT = static_cast<QRhiTextureRenderTarget*>(state.sgRenderTarget.rt);
 if (preserveColorContents) {
 textureRT->setFlags(textureRT->flags() | QRhiTextureRenderTarget::PreserveColorContents);
 } else {
 textureRT->setFlags(textureRT->flags() & ~QRhiTextureRenderTarget::PreserveColorContents);
 }
 }
 }

 state.context->renderNextFrame(renderer);

 { // after render
 if (!softwareRenderer) {
 // TODO: get damage area from QRhi renderer
 m_damageRing.add_whole();
 // ###: maybe Qt bug? Before executing QRhi::endOffscreenFrame, we may
 // use the same QSGRenderer for multiple drawings. This can lead to
 // rendering the same content for different QSGRhiRenderTarget instances
 // when using the RhiGles backend. Additionally, considering that the
 // result of the current drawing may be needed when drawing the next
 // sourceIndex, we should let the RHI (Rendering Hardware Interface)
 // complete the results of this drawing here to ensure the current
 // drawing result is available for use.
 wd->rhi->finish();
 } else {
 auto currentImage = getImageFrom(state.renderTarget);
 Q_ASSERT(currentImage && currentImage == softwareRenderer->m_rt.paintDevice);
 currentImage->setDevicePixelRatio(1.0);
 const auto scaleTF = QTransform::fromScale(devicePixelRatio, devicePixelRatio);
 const auto scaledFlushRegion = scaleTF.map(softwareRenderer->flushRegion());
 PixmanRegion scaledFlushDamage;
 bool ok = WTools::toPixmanRegion(scaledFlushRegion, scaledFlushDamage);
 Q_ASSERT(ok);

 {
 PixmanRegion damage;
 m_damageRing.get_buffer_damage(state.bufferAge, damage);

 if (viewportRect.isValid()) {
 QRect imageRect = (currentImage->operator const QImage &()).rect();
 QRegion invalidRegion(imageRect);
 invalidRegion -= viewportRect;
 if (!scaledFlushRegion.isEmpty())
 invalidRegion &= scaledFlushRegion;

 if (!invalidRegion.isEmpty()) {
 QPainter pa(currentImage);
 for (const auto r : std::as_const(invalidRegion))
 pa.fillRect(r, softwareRenderer->clearColor());
 }
 }

 if (!damage.isEmpty() && state.lastRT.first != state.buffer && !state.lastRT.second.isNull()) {
 auto image = getImageFrom(state.lastRT.second);
 Q_ASSERT(image);
 Q_ASSERT(image->size() == state.pixelSize);

 // TODO: Don't use the previous render target, we can get the damage region of QtQuick
 // before QQuickRenderControl::render for qw_damage_ring, and add dirty region to
 // QSGAbstractSoftwareRenderer to force repaint the damage region of current render target.
 QPainter pa(currentImage);

 PixmanRegion remainderDamage;
 ok = pixman_region32_subtract(remainderDamage, damage, scaledFlushDamage);
 Q_ASSERT(ok);

 int count = 0;
 auto rects = pixman_region32_rectangles(remainderDamage, &count);
 for (int i = 0; i < count; ++i) {
 auto r = rects[i];
 pa.drawImage(r.x1, r.y1, *image, r.x1, r.y1, r.x2 - r.x1, r.y2 - r.y1);
 }
 }
 }

 if (!isRootItem(source.source))
 applyTransform(softwareRenderer, state.worldTransform.inverted().toTransform());
 m_damageRing.add(scaledFlushDamage);
 }
 }

 if (auto dr = qobject_cast<QSGDefaultRenderContext*>(state.context)) {
 QRhiResourceUpdateBatch *resourceUpdates = wd->rhi->nextResourceUpdateBatch();
 dr->currentFrameCommandBuffer()->resourceUpdate(resourceUpdates);
 }

 if (shouldCacheBuffer())
 wTextureProvider()->setBuffer(state.buffer);
}

处理完画面以后，如果需要上屏画面，就调用 commit 把画面送到屏幕上。

bool OutputHelper::commit(WBufferRenderer *buffer)
{
 if (output()->offscreen())
 return true;

 if (!buffer || !buffer->currentBuffer()) {
 Q_ASSERT(!this->buffer());
 return WOutputHelper::commit();
 }

 setBuffer(buffer->currentBuffer());

 if (m_lastCommitBuffer == buffer) {
 if (pixman_region32_not_empty(&buffer->damageRing()->handle()->current))
 setDamage(&buffer->damageRing()->handle()->current);
 }

 m_lastCommitBuffer = buffer;

 return WOutputHelper::commit();
}

还会判断是否有硬件加速（GPU），会优先使用硬件来加速计算过程。

} else {
 state.worldTransform.optimize();

 bool flipY = wd->rhi ? !wd->rhi->isYUpInNDC() : false;
 if (state.renderTarget.mirrorVertically())
 flipY = !flipY;

 if (viewportRect.isValid()) {
 QRect vr = viewportRect;
 if (flipY)
 vr.moveTop(-vr.y() + state.pixelSize.height() - vr.height());
 renderer->setViewportRect(vr);
 } else {
 renderer->setViewportRect(QRect(QPoint(0, 0), state.pixelSize));
 }

 QRectF rect = sourceRect;
 if (!rect.isValid())
 rect = QRectF(QPointF(0, 0), QSizeF(state.pixelSize) / devicePixelRatio);

 const float left = rect.x();
 const float right = rect.x() + rect.width();
 float bottom = rect.y() + rect.height();
 float top = rect.y();

 if (flipY)
 std::swap(top, bottom);

 QMatrix4x4 matrix;
 matrix.ortho(left, right, bottom, top, 1, -1);

 QMatrix4x4 projectionMatrix, projectionMatrixWithNativeNDC;
 projectionMatrix = matrix * state.worldTransform;

 if (wd->rhi && !wd->rhi->isYUpInNDC()) {
 std::swap(top, bottom);

 matrix.setToIdentity();
 matrix.ortho(left, right, bottom, top, 1, -1);
 }
 projectionMatrixWithNativeNDC = matrix * state.worldTransform;

 renderer->setProjectionMatrix(projectionMatrix);
 renderer->setProjectionMatrixWithNativeNDC(projectionMatrixWithNativeNDC);

 auto textureRT = static_cast<QRhiTextureRenderTarget*>(state.sgRenderTarget.rt);
 if (preserveColorContents) {
 textureRT->setFlags(textureRT->flags() | QRhiTextureRenderTarget::PreserveColorContents);
 } else {
 textureRT->setFlags(textureRT->flags() & ~QRhiTextureRenderTarget::PreserveColorContents);
 }
}

Surface 渲染

在 Treeland 中，为 Surface 创建了 WSurfaceItem，用于表示一个窗口，并创建了 WSurfaceContent 作为 WSurfaceItem 的 delegate。

void WSurfaceItemPrivate::initForDelegate()
{
 Q_Q(WSurfaceItem);

 std::unique_ptr<QQuickItem> newContentContainer;

 if (!delegate) {
 if (getItemContent()) {
 Q_ASSERT(!delegateIsDirty);
 return;
 }

 delegateIsDirty = false;
 auto contentItem = new WSurfaceItemContent(q);
 if (surface)
 contentItem->setSurface(surface);
 contentItem->setCacheLastBuffer(!surfaceFlags.testFlag(WSurfaceItem::DontCacheLastBuffer));
 contentItem->setSmooth(q->smooth());
 contentItem->setLive(!q->flags().testFlag(WSurfaceItem::NonLive));
 QObject::connect(q, &WSurfaceItem::smoothChanged, contentItem, &WSurfaceItemContent::setSmooth);
 newContentContainer.reset(contentItem);
 } else if (delegateIsDirty) {
 auto obj = delegate->createWithInitialProperties({{"surface", QVariant::fromValue(q)}}, qmlContext(q));
 if (!obj) {
 qWarning() << "Failed on create surface item from delegate, error mssage:"
 << delegate->errorString();
 return;
 }

 delegateIsDirty = false;
 auto contentItem = qobject_cast<QQuickItem*>(obj);
 if (!contentItem)
 qFatal() << "SurfaceItem's delegate must is Item";

 newContentContainer.reset(new QQuickItem(q));
 QQmlEngine::setObjectOwnership(contentItem, QQmlEngine::CppOwnership);
 contentItem->setParent(newContentContainer.get());
 contentItem->setParentItem(newContentContainer.get());
 }

 if (!newContentContainer)
 return;

 newContentContainer->setZ(qreal(WSurfaceItem::ZOrder::ContentItem));

 if (contentContainer) {
 newContentContainer->setPosition(contentContainer->position());
 newContentContainer->setSize(contentContainer->size());
 newContentContainer->setTransformOrigin(contentContainer->transformOrigin());
 newContentContainer->setScale(contentContainer->scale());

 contentContainer->disconnect(q);
 contentContainer->deleteLater();
 }
 contentContainer = newContentContainer.release();
 updateEventItem(false);
 updateBoundingRect();
 if (eventItem)
 updateEventItemGeometry();

 Q_EMIT q->contentItemChanged();
}

之后当 WSurfaceItem 需要更新画面时，就能调用 updatePaintNode 更新渲染。

QSGNode *WSurfaceItemContent::updatePaintNode(QSGNode *oldNode, UpdatePaintNodeData *)
{
 W_D(WSurfaceItemContent);

 auto tp = wTextureProvider();
 if (d->live || !tp->texture()) {
 auto texture = d->surface ? d->surface->handle()->get_texture() : nullptr;
 if (texture) {
 tp->setTexture(qw_texture::from(texture), d->buffer.get());
 } else {
 tp->setBuffer(d->buffer.get());
 }
 }

 if (!tp->texture() || width() <= 0 || height() <= 0) {
 delete oldNode;
 return nullptr;
 }

 auto node = static_cast<QSGImageNode*>(oldNode);
 if (Q_UNLIKELY(!node)) {
 node = window()->createImageNode();
 node->setOwnsTexture(false);
 QSGNode *fpnode = new WSGRenderFootprintNode(this);
 node->appendChildNode(fpnode);
 }

 auto texture = tp->texture();
 node->setTexture(texture);
 const QRectF textureGeometry = d->bufferSourceBox;
 node->setSourceRect(textureGeometry);
 const QRectF targetGeometry(d->ignoreBufferOffset ? QPointF() : d->bufferOffset, size());
 node->setRect(targetGeometry);
 node->setFiltering(smooth() ? QSGTexture::Linear : QSGTexture::Nearest);

 return node;
}

而使用 delegate 的目的是为了能让多个 WSurfaceItem 使用相同的窗口画面，例如某些场景需要临时创建一个窗口的分身，窗口切换列表、多任务视图等。

QSGTextureProvider *WSurfaceItemContent::textureProvider() const
{
 if (QQuickItem::isTextureProvider())
 return QQuickItem::textureProvider();

 return wTextureProvider();
}

WSGTextureProvider *WSurfaceItemContent::wTextureProvider() const
{
 W_DC(WSurfaceItemContent);

 auto w = qobject_cast<WOutputRenderWindow*>(d->window);
 if (!w || !d->sceneGraphRenderContext() || QThread::currentThread() != d->sceneGraphRenderContext()->thread()) {
 qWarning("WQuickCursor::textureProvider: can only be queried on the rendering thread of an WOutputRenderWindow");
 return nullptr;
 }

 if (!d->textureProvider) {
 d->textureProvider = new WSGTextureProvider(w);
 if (d->surface) {
 if (auto texture = d->surface->handle()->get_texture()) {
 d->textureProvider->setTexture(qw_texture::from(texture), d->buffer.get());
 } else {
 d->textureProvider->setBuffer(d->buffer.get());
 }
 }
 }
 return d->textureProvider;
}

Treeland 使用 WQuickTextureProxy 创建窗口的代理显示，而其中就是获取 WSurfaceItem 的 textureProvider。

QSGTextureProvider *WQuickTextureProxy::textureProvider() const
{
 if (QQuickItem::isTextureProvider())
 return QQuickItem::textureProvider();

 W_DC(WQuickTextureProxy);
 if (!d->sourceItem)
 return nullptr;

 return d->sourceItem->textureProvider();
}

这样多个 proxy 就可以显示同一个窗口的内容，比 QML 的 ShaderEffectSource 效率更高。

结尾

上述仅仅是 Treeland 实现 Qt 和 wlroots 缝合的一部分流程，实际上对事件的处理就十分复杂，不止键盘输入，还需要处理光标、触控、触摸等其他设备。还有光标的绘制也需要区分硬光标和软光标，渲染画面时的硬件加速及软件实现等。

后续准备写一下光标相关的处理，以及还没介绍 Treeland 的画面是怎么绘制的。

Treeland：DDE 进步的阶梯

justforlxz — Fri, 01 Nov 2024 04:00:00 +0000

回顾

DDE 在 v15 时期，使用 Mutter 作为带合成器的窗管，以及 Metacity 这种不带合成器的窗管，一个是在高性能设备上使用，一个是为低性能设备上使用。

在 V20 时期，DDE 更换 KWin 当窗口管理器，由于 KWin 自带有关闭合成器的模式，所以 DDE 也放弃了 Metacity 作为备用窗管的选项。

Mutter

Mutter 是 GNOME 开发的带有合成器功能的窗口管理器。

Mutter

Metacity

一个不带有合成器功能的窗口管理器。

Metacity

KWin

KWin 是 KDE 开发的，具有动态切换渲染后端，动态开关合成器功能的窗口管理器。

KWin

需求和指标

在一个面向用户的产品中，拥有友好的界面是一个非常重要的事情，所以设计师给了一大堆非常好看的界面交互设计。

但更多的动画效果，以及更多的组件交互，通常就要求使用更多的资源，更多的内存，更高的功耗。

设计师说要动画华丽，要动画流畅，要优秀的用户体验。

架构师说要低资源占用，低内存，不能卡。

虽说一切目标都是为了用户体验，但两个大指标在实现上竟然是冲突的，那么如何平衡二者，就需要研发献祭一些头发了。

对比

在Linux下目前有两个技术栈，一个是历史悠久的X11，另一个是较新的 Wayland。

接下来，跟随我一起来对比两个技术。

X11

架构

X11采用了比较老的客户端-服务器架构。应用程序通过X服务器与硬件设备进行通信，这种架构非常灵活，支持网络传输，使得远程显示变得可能。然而，X11协议复杂且过时，在很多方面不再符合现代的图形需求。

性能

由于其设计较老，X11在一些现代场景下的性能表现不佳。它需要依赖很多扩展和补丁才能实现现代图形效果，例如合成管理器（Compositor）等。这些叠加的复杂性导致了额外的性能开销。

安全性

X11的安全性问题比较明显，因为所有应用程序都可以访问彼此的窗口信息。这意味着一个恶意程序可以读取或干扰其他程序的输入输出。虽然可以通过一些扩展和工具加强安全性，但这并不是X11的设计初衷。

可扩展性和兼容性

由于存在了几十年，X11有非常广泛的应用支持和兼容性。许多老的应用程序和桌面环境仍然依赖于X11协议，尤其是在远程桌面和某些专业领域。

输入设备支持

由于其历史悠久，X11对各种输入设备的支持相当成熟。但随着新硬件和新输入技术的出现，X11的设计显得有些不灵活，特别是在多点触控和手势支持方面。

远程桌面和网络透明性

X11的一个优势是其天然的网络透明性。它支持通过网络将显示内容远程传输，这是很多专业领域（如科学计算、服务器管理）中非常有用的功能。

Wayland

架构

Wayland采用的是更简单的设计，去掉了X服务器的复杂层次。消除了很多中间环节，提高了效率和响应速度。Wayland专注于本地显示，不像X11那样直接支持远程显示。

性能

Wayland的设计更加现代化，它简化了渲染过程，减少了中间层，性能提升显著。特别是在动画和窗口操作方面，Wayland通常比X11更为流畅。

安全性

Wayland在设计时考虑了安全性。应用程序之间的隔离更强，应用程序无法访问其他程序的图像或输入输出，这显著提高了系统的整体安全性。

可扩展性和兼容性

尽管Wayland逐渐被主流桌面环境（如GNOME、KDE等）支持，但其应用生态仍然不如X11广泛。在某些老旧或专业的应用场景中，可能需要通过兼容层（如XWayland）来运行基于X11的应用程序。

输入设备支持

Wayland针对现代硬件进行了优化，尤其是在多点触控、触摸板手势等方面有更好的支持。此外，它对显示器的DPI缩放、刷新率等也有更灵活的处理。

远程桌面和网络透明性

Wayland默认没有X11那样的网络透明性功能。这意味着原生的远程桌面功能比较有限，尽管可以通过一些第三方工具或协议（如VNC、RDP）实现远程桌面，但这不是Wayland的核心功能。

总结

总结下来，X11已经进入维护阶段，不再进行大幅更新。随着时间的推移，开发者和社区的注意力逐渐转移到Wayland上，X11可能会逐步淡出主流桌面环境。Wayland正在逐步成为Linux桌面的标准。随着越来越多的应用程序和桌面环境转向支持Wayland，其生态系统正在不断成熟和扩展。

架构设计

从技术层面上，我们认为是时候更新技术方案了，曾经的X11+窗口管理器+合成器的模式，灵活但不满足需求，Wayland从底层就将三者融合在了一起，并且更新画面是以每幅完整的画面作为基础的，这确保了画面不会因为不同窗口更新界面的时机不一致导致画面撕裂。

更重要的一点，自研的窗口管理器，它是以实现DDE的需求为目的的，这是第三方窗口管理器不能比拟的。通常使用第三方的项目时，都要进行大量破坏性的调整，导致fork后的项目无法和上游同步，不能及时获取更新和修复，并且第三方的项目已经发展了很长时间，内部有许多DDE用不上、甚至冲突的功能，都需要进行大量调整，更加剧了维护成本。

所以 DDE 决定开发一个新的窗口管理器——Treeland。

Treeland在底层使用 wlroots 作为 Wayland 的基础库，不修改 wlroots 的代码，也就意味着可以随时同步上游进度，获得新的功能与修复。上层使用 Qt，可以充分利用公司内大量的 Qt 开发者，不再需要一直有专人负责特定项目，让DDE的技术栈更加统一。

Treeland 结构图

简单介绍一些 Treeland 里涉及的重要项目。

QWlroots
wlroots 的 Qt 绑定，将 wayland 信号转换成 Qt 风格的信号。
Waylib
将 wlroots 中的组件封装成 QtQuick 对象，使用 QPA 为 Treeland 提供事件转换与分发。
DtkDeclarative
DTK 的 QtQuick 组件，封装了大部分 DTK style 的控件。

在 Waylib中，会使用到 Qt 的 QPA 功能，将 wlroots 作为一个新的平台来处理一部分功能。

QPA 在 Treeland 中有着举足轻重的地位，来自系统底层的事件会先进入到 Waylib中，在 Waylib 里将事件转换成 Qt 内部事件，发送给上层。这样 Treeland 就可以在 QtQuick 中确定用户的点击位置、按键事件等行为。当用户点击的是窗口时，Treeland 还会通过 Waylib 生成一个事件，通过 seat 的接口发送给客户端，完成界面交互。

Treeland 处理底层事件与上层事件的流程

界面效果与优化

Treeland 作为一个窗口管理器，最重要的功能还是对窗口的管理及显示效果的控制，Treeland 所有的窗口都带有圆角和阴影，以及一些窗口模糊效果。

圆角

DDE及deepin社区应用都大量采用了窗口圆角的设计，由合成器提供圆角裁剪可以带来更加统一的界面设计。

红色为QtQuick圆角/黄色为Treeland圆角

QtQuick 圆角是由 Rectangle 组件提供的，它只能同时对四个角进行操作（红色块）。但 DTK 程序具备异形窗口的能力，所以 Treeland 提供了自己的裁圆角控件（黄色块）。
新的造型算法、几何顶点数量比 QtQuick 原生的 Rectangle 减少50%，GPU顶点渲染和三角细分性能提升100%。
采用新的抗锯齿算法，提高了GPU片元着色器性能，相比于普通 4xMSAA 抗锯齿算法，计算量减少1/4。

模糊

QtQuick 模糊控件

QtQuick 的模糊组件仅支持对控件自身进行模糊，这并不符合 Treeland 的需求。

Treeland 模糊控件

Treeland 重新实现了模糊组件，能从显存里获取组件下方图像数据，再使用融合的模糊算法优化性能。

阴影

Qt Quick 有一个 BorderImage 组件，它能以九宫格的方式，四个角保持不变，四边和中间的部分拉伸，来达到在组件底部充当装饰的效果。并通过 ImageProvider 的机制，手动控制图片资源的创建。

Treeland 使用 BorderImage 作为窗口阴影贴图，通过 ImageProvider 手动创建贴图材质，在相同大小下可复用同一份材质。

动画

Treeland 直接使用 QtQuick 提供的动画组件，来为界面提供动画效果。

使用 State 和 Transition 为组件定义属性变化，例如窗口最大化和还原，两个 State 切换会触发不同的 Transition 执行属性变化，在属性变化时，使用 QtQuick 的动画组件完成动画播放。

多用户

Treeland 作为解决方案的一部分，目的之一就是多用户共用合成器。在经典模式下，不同用户的切换需要在 tty 层面前端程序转移控制权，每个用户独占一个 tty 进行画面上屏。但切换tty所需的工作量不小，这导致切换时屏幕的缓冲区被不同的程序覆盖，给人的观感就是屏幕闪烁了一下，甚至是黑屏一会儿。

DDM

通过上图可以看出，LightDM模式下，每个用户拥有完整的一套进程组，都需要运行窗管、任务栏、文件管理器等。不同的用户会单独占用一个 tty，那么用户切换时，必然伴随着底层 DRM 以及显卡驱动等操作的切换，带来的结果就是会看到闪黑屏，而且两个用户都要跑一个锁屏界面来维持”假装是同一个界面“，也带来了跨用户进程的信息同步难题。

而 DDM 和 Treeland 重新设计了工作流程，将 Treeland 单独抽离出来，每个用户都通过相同的一套机制将窗口画面发送给 Treeland，而 Treeland 负责最终的画面合成以及上屏。

带来的好处显而易见，内存方面节省了窗管、锁屏等进程，切换用户也不会有黑屏闪烁，状态也不用想办法同步了。

一个简化的 DDM 与 Treeland 的多用户登录流程

与 systemd 的集成

DDE 的每一个用户会话，都已切换至 systemd 服务，而非所有进程都挂载到会话入口的服务上。这样做有很多好处，包括快速重启桌面环境，而非注销再登录。远程桌面的铺垫，会话的启动不再局限于本地会话。

在 Treeland 模式下，DDE 会加载一个单独的服务，用于为用户会话注入显示环境变量。该服务使用 systemd 提供的 socket 机制实行懒加载，当 DDE 需要显示窗口时，即时向 Treeland 注册，完成用户显示服务的初始化。当 Treeland 崩溃重启时，该服务也会等待 Treeland 启动完成，并再次连接回 Treeland，确保用户侧的窗口能正常显示。

多用户登录时的基本流程

总结

本文介绍了深度操作系统（DDE）在窗口管理器方面的演进，从早期使用Mutter和Metacity，到后来采用KWin，最终决定开发自己的窗口管理器Treeland。Treeland基于wlroots和Qt技术栈，实现了更好的性能和更统一的技术框架。

本文概述了 Treeland 的技术架构、界面效果优化（如圆角、模糊、阴影等），以及其在多用户场景下的优势。此外，还介绍了Treeland与systemd的集成，展示了DDE在系统架构和用户体验方面的持续创新和改进。

DDE Qt 6.8 适配说明

DDE 移植兴趣小组 — Fri, 25 Oct 2024 00:00:00 +0000

DDE Qt 6.8 适配说明

Qt 6.8 发布已经有一段时间了，各个发行版尝试移植 DDE 时发现包括 dde-shell 在内的几个组件存在比较明显的问题，DDE 小组进行了相关的紧急修复。由于 DDE 部分项目也在分叉维护的状态，为了方便各位移植人员有效进行移植，故在此罗列相关注意事项。

注：笔者所测试的环境为 Arch Linux，下述为 2024/10/25 testing 仓库状态下的测试结论。若未另行说明，则下述涉及到的项目名称仍然使用了与 DDE 对应项目原始仓库的名称，而非各个发行版下的包名。

[!NOTE] 2024/11/06更新：对于 dde-launchpad、dde-tray-loader、dde-shell 目前均有新的维护分支版本，部分版本中已包含了下述中涉及到的一些 patch 的修复。本博客目前只更新了实机验证可用的新 tag 版本，但你也可以尝试未验证但位于维护分支的新 tag。

分支与 tag 说明

因维护需要，对于部分 DDE 组件（dde-shell、dde-launchpad、dde-tray-loader），我们对 deepin 23 所使用的分支创建了名为 release/beige 的维护分支。也会在维护分支上打对应的维护更新用的 tag。

由于 deepin 现阶段的提测流程需要对提测版本打 tag，故我们对主干（master）分支也会打 tag。为了在不与现行规范冲突的情况下尽可能表示区分，我们使用格式为 x.99.z 的 tag 标记此版本是尚在开发中的版本。开发中的 tag 版本事实上在满足一定条件下也可供外部使用，但我们不保证 x.99.z 中 z 位更新时的兼容性，故仍然建议优先使用 release/beige 上的 tag 版本。

Qt 6 Wayland

由于 dde-shell 的托盘加载部分（dde-tray-loader）使用了 Wayland（即便是 x11 环境也如此）实现应用的嵌入，故对 Qt 6 的 wayland 组件存在依赖。有下述两个 Patch 需要应用到 Qt 6 Wayland 组件之上：

dde-shell

Patch 说明

升级至 Qt 6.8 后，dde-shell 可能存在面板无任何内容的情况，就于此问题，需要应用这个 patch：

https://github.com/linuxdeepin/dde-shell/commit/46871c83cf8ecfcf83bf2fb49e1f09af997eca96

版本建议

若目标发行版原本在使用 1.0.0 版本，则建议至少更新到 1.0.2
1.0.3 以上版本依赖 treeland-protocols 项目，进行打包即可，建议对齐打包后至少更新 dde-shell 至 1.0.4
- 由于 treeland-protocols 更新了其 CMake 支持中目标名称的大小写，故你需要打这个小 patch （或者手动进行相应调整）： https://github.com/linuxdeepin/dde-shell/commit/b3f342c094354e4ba87ac1da4cf1a380556b2a3b
dde-shell 主干分支存在 1.99.1，但包括此版本在内的主干分支已不再在任务栏提供启动器图标，故需要配合启动器主干分支使用（启动器暂无 1.99.z 版本）

tl;dr：建议打包 treeland-protocols 后更新至至少 1.0.4。

treeland-protocols

被 dde-shell 1.0.3 以上版本所依赖。

版本建议

建议打包/更新至 0.4.1。

dde-tray-loader

Patch 说明

任务栏托盘区域的弹出面板（例如点击时间组件后的面板）早期版本有位置不正确的问题，需要应用这个 patch： https://github.com/linuxdeepin/dde-tray-loader/commit/664b093b6a913764fedbac9110927f26978aa8c9 。最新版本（1.0.5 起）中已经修正相关问题。

版本建议

建议更新至 1.0.5。

dde-launchpad

Patch 说明

启动器的维护分支版本应该可以在无任何修改的情况下正常工作，尽管启动器小窗口模式的面板位置可能不对，但位置问题暂不计划在维护分支解决。

启动器主干分支不存在上述问题，但主干分支暂无 1.99.z tag。

版本建议

在之前的移植过程中发现小窗口搜索结果界面可能存在显示错位问题，此问题已在 1.0.6 修复，故建议更新至 1.0.6。

dde-application-manager

Patch 说明

不需要 patch。

版本建议

一个 deepin 23 的所谓“特性”即，父进程启动的子进程一般会被识别归属为父进程，会导致例如在终端启动 vscode，打开的 vscode 窗口会和终端共用相同图标的问题。此问题已经在最新维护版本得到解决。直接更新dde-shell （>= 1.0.4） dde-application-manager(>=1.2.16)版本即刻解决。

建议更新至 1.2.16。

DDE v23 发布说明

DDE 桌面环境小组 — Wed, 14 Aug 2024 11:00:00 +0000

deepin v23 将于 2024 年 8 月 15 日发布，这里为大家简要描述本次更新中，DDE 所涉及的变更，以及我们的进一步计划。

需注意，本文章是站在 DDE SIG 角度的，倾向于对 DDE 项目整体的技术内容进行描述，面向 DDE 开发者和对 DDE 开发感兴趣的读者，并非面向最终用户的特性概览文章。若您需要大众化的发布概览，请参阅 deepin 公众号、官方网站等提供的介绍文章。另外，如果你对 DDE 的移植感兴趣，请参阅另一篇侧重于移植相关事项的文章。

不同于 beta3 与 RC 所提供的发布说明，此次将整体介绍 DDE v23 相对 v20 的变化内容。

变化较大的默认组件

`dde-dock` → `dde-shell`

虽然观感上对用户的差异是任务栏整体的变化，但 dde-shell 项目所要承载的责任要远超于 dde-dock。dde-shell 旨在提供一个桌面环境级的外壳程序，使编写 DDE 桌面组件变得更轻松。例如它提供了允许你指定组件的层级关系、确定放置的屏幕位置等功能，并确保相应功能在 x11 与 Wayland 环境的表象均一致。这将使得桌面组件不必针对应用编写重复的代码来实现与桌面环境强相关的功能，并使得后续 x11 向 Wayland 切换变得更方便。当前，dde-shell 面向用户呈现的唯一主要组件即任务栏，而预计在后续，OSD、通知中心、剪切板等组件也都会逐渐进行迁移，由 dde-shell 统一管理。

另外，dde-shell 整体也从传统的 QtWidgets 项目变成了 QML 项目，这使得 GPU 加速可以被有效的利用，使得相应的界面交互、动效等更加流畅。关于“任务栏”这个 dde-shell 组件，也存在了较大变化。为了避免插件崩溃时连带整个任务栏组件一起崩溃的问题发生，任务栏区域采用了内嵌 Wayland 合成器的解决方案实现了相关逻辑。

`dde-launcher` → `dde-launchpad`

dde-launchpad 事实上是第一个试水 QML 的 DDE 桌面组件，由于 dde-launcher 存在大量的内部 model 状态维护不正确的问题以及界面问题，dde-launchpad 则对其进行了整体重构并将整个界面改用 QML 技术进行构建。如 dde-shell 一节中所述，这将使得整体的流畅度得以提升。

此外，由于 DDE 计划对应用程序进行相关的权限管控，dde-launchpad 也将应用程序列表的获取和管理从原本的 GIO 切换到了新的 dde-application-manager。

`dde-application-manager`

dde-application-manager 是一个后台服务，为需要获取应用列表以及启动应用程序的组件（文管、启动器、任务栏等）提供与管理相关数据，为启动的应用与组件设置恰当的 cgroup、环境变量等信息。尽管当下而言 dde-application-manager 并无特殊之处，但其为后续实现应用程序权限管控的计划提供了空间。

技术预览组件

我们在 v23 的开发过程中引入了技术预览组件的概念，而原本位于技术预览组件的两个主要项目（启动器与 shell）均已离开了技术预览阶段，现以正式版的形式面向社区发布。而目前仍然位于技术预览阶段的项目即 TreeLand 与 deepin-im 了。

为了使得 v23 顺利发布、尽早发布，我们在 RC 阶段即将精力完全投入在了现有组件的缺陷修复上，TreeLand 与 deepin-im 项目均暂无显著成果可供分享，后续我们会在恰当的时候为大家详细介绍这两个项目。

后续计划

如之前计划所安排，dde-shell 现已走出技术预览并承载了任务栏的显示职责。dde-shell 的初衷之一是使桌面环境更加模块化，在后续，会有更多桌面组件成为 dde-shell 的一部分。我们也欢迎社区开发者开始尝试使用 dde-shell 编写一些自己觉得有趣的东西，并与我们讨论对 shell 相关设计与接口的体验，一同完善 dde-shell。如果你对这相关的话题感兴趣，欢迎加入 DDE SIG 的 Matrix 群聊 (#dde:matrix.org) 之中来。

接下来，wayland 会话支持也会变成主要目标，treeland 将会逐步继续完善，并在恰当的时机提供给大家。

此外，为了方便非 deepin 发行版的用户和开发者使用 DDE，我们也仍然和上次一样提供了一篇移植注意事项博客。笔者也是 DDE 移植 SIG 的成员，对应的文章现已发布到 DDE 移植小组。如果您感兴趣，可在此阅读。如果你本身在参与 DDE 的移植工作，那么也欢迎你加入 DDE 移植小组（#dde-port:deepin.org 或 https://t.me/ddeport）。

最后，感谢你读到这里。如有任何问题，欢迎在我们的开发者群（#deepin-community:deepin.org）进行讨论。

DDE v23 RC 发布说明

DDE 桌面环境小组 — Wed, 15 May 2024 09:00:00 +0000

deepin v23 RC 将于 2024 年 5 月 15 日发布，这里为大家简要描述本次更新中，DDE 所涉及的变更，以及我们的进一步计划。

需注意，本文章倾向于对 DDE 项目整体的技术内容进行描述，面向 DDE 开发者和对 DDE 开发感兴趣的读者，并非面向最终用户的特性概览文章。另外，如果你对 DDE 的移植感兴趣，请参阅另一篇侧重于移植相关事项的文章。

变化较大的默认组件

相比 deepin v23 beta3 而言，在于 deepin v23 RC 发布的 DDE 中，有一个项目得到了较大规模的重构，并随 RC 默认提供给各位用户。即：

dde-shell

dde-shell 旨在提供一个桌面环境级的外壳程序，使编写 DDE 桌面组件变得更轻松。这个项目在 beta3 阶段为技术预览状态，而现阶段，dde-shell 则走出了技术预览，并取代了原本的 dde-dock 项目来展示任务栏组件。

此外，需要注意的是，dde-launchpad 项目也转而默认提供 dde-shell 插件的形式来提供启动器组件。

技术预览组件

非技术用户请慎重启用技术预览功能

deepin v23 beta2 时，我们提供了一个需要用户手动安装的 dcc-insider-plugin 插件，称为技术预览插件。这个组件旨在帮助用户方便的测试 deepin 未来版本中计划提供但仍不稳定的系统组件。需要注意的是，为了加快版本迭代速度，使 v23 首个稳定版可以更快面向用户发布，故这个组件在 RC 阶段并未进行过较多测试，因而可能不会按预期行为工作，故我们目前不建议您使用此插件。

treeland / ddm
deepin-im

treeland 与 deepin-im 这两个组件在 beta3 到 RC 的阶段中并无太大显著变化。其中，treeland 项目原本提供了合成器与 DM 两个功能，而现在，treeland 与 DM 也进行了拆分，后者被拆分到了 ddm 仓库之中。

后续计划

如之前计划所安排，dde-shell 现已走出技术预览，但 dde-shell 仍有很多需要进一步完善的地方。一些用户会注意到 dde-shell 版的任务栏缺失了一些原本 dde-dock 项目所提供的功能，此类特性会后续逐步补充上来。另外 dde-shell 也会继续向原本的目标迈进，我们会进一步将其他桌面组件转换为 dde-shell 插件的形式进行维护。使得桌面环境模块化之余，也为 wayland 支持作出更好的准备。

另外，由于 dde-shell 的初衷之一是使桌面环境更加模块化，我们也欢迎社区开发者开始尝试使用 dde-shell 编写一些自己觉得有趣的东西，并与我们讨论对 shell 相关设计与接口的体验，一同完善 dde-shell。如果你对这相关的话题感兴趣，欢迎加入 DDE SIG 的 Matrix 群聊 (#dde:matrix.org) 之中来。

接下来，wayland 会话支持也会变成主要目标（尽管 v23 首个正式版仍然可能不会提供 wayland 会话支持），treeland 与 ddm 将会逐步继续完善，并在恰当的时机提供给大家。

此外，由于 DDE 在 beta3 与 RC 的变化仍然较大，我们也仍然和上次一样提供了一篇移植注意事项博客。笔者也是 DDE 移植 SIG 的成员，对应的文章现已发布到 DDE 移植小组。如果您感兴趣，可在此阅读。如果你本身在参与 DDE 的移植工作，那么也欢迎你加入 DDE 移植小组（#dde-port:deepin.org 或 https://t.me/ddeport）。

最后，感谢你读到这里。如有任何问题，欢迎在我们的开发者群（#deepin-community:deepin.org）进行讨论。

linux内存压缩技术

deepin 社区官方博客 — Mon, 18 Mar 2024 05:50:31 +0000

技术背景

顾名思义，内存压缩就是压缩内存，节省内存空间。相信对于搞技术的人来说，压缩这个词并不陌生，一想到这个词，我们首先想到的是压缩可以降低占用空间，使同样的空间可以存放更多的东西。内存无论多大，总是会有不够用的时候，或者说我们总是想在尽量低的成本控制下，达到系统最优，这个时候还是有必要引入诸如内存压缩的功能来优化系统内存占用。当系统内存紧张的时候，会将文件页丢弃或回写回磁盘（如果是脏页），还可能会触发LMK杀进程进行内存回收。这些被回收的内存如果再次使用都需要重新从磁盘读取，而这个过程涉及到较多的IO操作。就目前的技术而言，IO的速度远远慢于这RAM操作速度。因此，如果频繁地做IO操作，不仅影响flash使用寿命，还严重影响系统性能。内存压缩是一种让IO过程平滑过渡的做法, 即尽量减少由于内存紧张导致的IO，提升性能。

图：内存管理大体框架（内存压缩技术处于内存回收memory reclaim部分中）

主流内存压缩技术

目前linux内核主流的内存压缩技术主要有3种：zSwap, zRAM, zCache。下面我们依次对几种方式进行一个简要的说明

zSwap

zSwap是在memory与flash之间的一层“cache”,当内存需要swap出去磁盘的时候，先通过压缩放到zSwap中去，zSwap空间按需增长。达到一定程度后则会按照LRU的顺序(前提是使用的内存分配方法需要支持LRU)将就最旧的page解压写入磁盘swap device，之后将当前的page压缩写入zSwap。

zswap本身存在一些缺陷或问题:

如果开启当zswap满交换出backing store的功能, 由于需要将zswap里的内存按LRU顺序解压再swap out, 这就要求内存分配器支持LRU功能。
如果不开启当zswap满交换出backing store的功能, 和zRam是类似的。

zRram

zRram即压缩的内存，使用内存模拟block device的做法。实际不会写到块设备中去，只会压缩后写到模拟的块设备中，其实也就是还是在RAM中，只是通过压缩了。由于压缩和解压缩的速度远比读写IO好，因此在移动终端设备广泛被应用。zRam是基于RAM的block device, 一般swap priority会比较高。只有当其满，系统才会考虑其他的swap devices。当然这个优先级用户可以配置。

zRram本身存在一些缺陷或问题:

zRam大小是可灵活配置的, 那是不是配置越大越好呢? 如果不是,配置多大是最合适的呢?
使用zRam可能会在低内存场景由于频繁的内存压缩导致kswapd进程占CPU高, 怎样改善?
增大了zRam配置,对系统内存碎片是否有影响?

要利用好zRam功能, 并不是简单地配置了就OK了, 还需要对各种场景和问题都做好处理, 才能发挥最优的效果。

zCache

zCache是oracle提出的一种实现文件页压缩技术，也是memory与block dev之间的一层“cache”,与zswap比较接近，但zcache目前压缩的是文件页，而zSwap和zRAM压缩是匿名页。

zcache本身存在一些缺陷或问题:

有些文件页可能本身是压缩的内容, 这时可能无法再进行压缩了；
zCache目前无法使用zsmalloc, 如果使用zbud,压缩率较低；
使用的zbud/z3fold分配的内存是不可移动的, 需要关注内存碎片问题；

内存压缩主流的内存分配器

Zsmalloc

zsmalloc是为ZRAM设计的一种内存分配器。内核已经有slub了，为什么还需要zsmalloc内存分配器？这是由内存压缩的场景和特点决定的。zsmalloc内存分配器期望在低内存的场景也能很好地工作，事实上，当需要压缩内存进行zsmalloc内存分配时，内存一般都比较紧张且内存碎片都比较严重了。如果使用slub分配，很可能由于高阶内存分配不到而失败。另外，slub也可能导致内存碎片浪费比较严重，最坏情况下，当对象大小略大于PAGE_SIZE/2时，每个内存页接近一半的内存将被浪费。

实测发现，anon pages的平均压缩比大约在1:3左右，所以compressed anon page size很多在1.2K左右。如果是Slub，为了分配大量1.2K的内存，可能内存浪费严重。zsmalloc分配器尝试将多个相同大小的对象存放在组合页（称为zspage）中，这个组合页不要求物理连续，从而提高内存的使用率。

需要注意的是, 当前zsmalloc不支持LRU功能, 旧版本内核分配的不可移动的页, 对内存碎片影响严重, 但最新版本内核已经是支持分配可移动类型内存了。

Zbud

zbud是一个专门为存储压缩page而设计的内存分配器。用于将2个objects存到1个单独的page中。zbud是可以支持LRU的, 但分配的内存是不可移动的。

Z3fold

z3fold是一个较新的内存分配器, 与zbud不同的是, 将3个objects存到1个单独的page中,也就是zbud内存利用率极限是1:2, z3fold极限是1:3。同样z3fold是可以支持LRU的, 但分配的内存是不可移动的。

内存压缩技术与内存分配器组合

结合上面zSwap / zRam /zCache的介绍, 与zsmalloc/zbud/z3fold分别怎样组合最合适呢? 下面总结了一下, 具体原因可以看上面介绍的时候各类型的特点。

对比项	zsmalloc	zbud	z3fold
zSwap（有实际swap device）	×(不可用)	√(可用)	√(最佳)
zSwap（无实际swap device）	√(最佳)	√(可用)	√(可用)
zRam	√(最佳)	√(可用)	√(可用)
zCache	×(不可用)	√(可用)	√(最佳)

zRAM技术原理

zRam内存压缩技术是目前移动终端广泛使用的内存压缩技术。

软件框架

下图展示了内存管理大体的框架，内存压缩技术处于内存回收memory reclaim部分中。

再具体到zRam, 它的软件架构可以分为3部分：数据流操作，内存压缩算法，zram驱动。

实现原理

Zram内存压缩技术本质上就是以时间换空间。通过CPU压缩、解压缩的开销换取更大的可用内存空间。

我们主要描述清楚下面这2个问题： 1.什么时候会进行内存压缩？ 2.进行内存压缩/解压缩的流程是怎样的？

进行内存压缩的时机：

Kswapd场景：kswapd是内核内存回收线程，当内存watermark低于low水线时会被唤醒工作，其到内存watermark不小于high水线。
Direct reclaim场景：内存分配过程进入slowpath, 进行直接行内存回收。

下面是基于4.4内核理出的内存压缩、解压缩流程。内存回收过程路径进行内存压缩。会将非活跃链表的页进行shrink, 如果是匿名页会进行pageout, 由此进行内存压缩存放到ZRAM中，调用路径如下：

在匿名页换出到swap设备后，访问页时，产生页访问错误, 当发现“页表项不为空，但页不在内存中”，该页就是已换到swap区中，由此会开始将该页从swap区中重新读取，如果是ZRAM，则是解压缩的过程。调用路径如下：

内存压缩算法

目前比较主流的内存算法主要为LZ0, LZ4, ZSTD等。下面截取了几种算法在x86机器上的表现。各算法有各自特点，有以压缩率高的，有压缩/解压快的等，具体要结合需求场景选择使用。

zRAM技术应用

本节描述一下在使用ZRAM常遇到的一些使用或配置，调试的方法。

如何配置开启zRAM

配置内存压缩算法

下面例子配置压缩算法为lz4

echo lz4 > /sys/block/zram0/comp_algorithm

配置ZRAM大小

下面例子配置zram大小为2GB

echo 2147483648 > /sys/block/zram0/disksize

使能zram

mkswap /dev/zram0

swapon /dev/zram0

zRAM块设备个数设定

如果是编译为内核模块，那么可以在内核模块加载的时候，添加参数：insmod zram.ko num_devices=4

也可直接修改内核源代码，代码地址为： /drivers/block/zram/zram_drv.c

/* Module params (documentation at end) */
static unsigned int num_devices = 1;

修改num_devices为你想要的zram个数即可

压缩流的最大个数设定

这个是 3.15 版本及以后的 kernel 新加入的功能，3.15 版本之前的 zram 压缩都是使用一个压缩流（缓存 buffer 和算法私有部分）实现，每个写（压缩）操作都会独享压缩流，但是单压缩流如果出现数据奔溃或者卡住的现象，所有的写（压缩）操作将一直处于等待状态，这样效率非常低；而多压缩流的架构会让写（压缩）操作可以并行去执行，大大提高了压缩的效率和稳定性。

查看压缩流个数：默认是1，可以直接向proc文件写入，也可以直接更改代码方式来改变默认压缩流个数

cat /sys/block/zram0/max_comp_streams

设定压缩流个数：

echo 3 > /sys/block/zram0/max_comp_streams

其他参数

Name	Access	Description
disksize	RW	显示和设置该块设备的内存大小
initstate	RO	显示设备的初始化状态
reset	WO	重置设备
num_reads	RO	读数据的个数
failed_reads	RO	读数据失败的个数
num_write	RO	写数据的个数
failed_writes	RO	写数据失败的个数
invalid_io	RO	非页面大小对齐的I/O请求的个数
max_comp_streams	RW	最大可能同时执行压缩操作的个数
comp_algorithm	RW	显示和设置压缩算法
notify_free	RO	空闲内存的通知个数
zero_pages	RO	写入该块设备的全为的页面的个数
orig_data_size	RO	保存在该块设备中没有被压缩的数据的大小
compr_data_size	RO	保存在该块设备中已被压缩的数据的大小
mem_used_total	RO	分配给该块设备的总内存大小
mem_used_max	RW	该块设备已用的内存大小，可以写 1 重置这个计数参数到当前真实的统计值
mem_limit	RW	zram 可以用来保存压缩数据的最大内存
pages_compacted	RO	在压缩过程中可用的空闲页面的个数
compact	WO	触发内存压缩

swappiness含义简述

swappiness参数是内核倾向于回收匿名页到swap（使用的ZRAM就是swap设备）的积极程度，原生内核范围是0~100，参数值越大，表示回收匿名页到swap的比例就越大。如果配置为0，表示仅回收文件页，不回收匿名页。默认值为60。可以通过节点“/proc/sys/vm/swappiness”配置。

zRam相关的技术指标

zRAM大小及剩余空间

Proc/meminfo 中可以查看相关信息 SwapTotal：swap 总大小, 如果配置为ZRAM, 这里就是ZRAM总大小 SwapFree：swap 剩余大小, 如果配置为ZRAM, 这里就是ZRAM剩余大小

当然，节点 /sys/block/zram0/disksize 是最直接的。

zRAM压缩率

/sys/block/zram/mm_stat 中有压缩前后的大小数据，由此可以计算出实际的压缩率 orig_data_size：压缩前数据大小，单位为bytes compr_data_size ：压缩后数据大小，单位为bytes

换出/换入swap区的总量

proc/vmstat 中中有相关信息 pswpin:换入总量，单位为page pswout:换出总量，单位为page

zRam相关优化

上面提到zRam的一些缺陷, 怎么去改善呢?

zRam大小是可灵活配置的, 那是不是配置越大越好呢? 如果不是配置多大是最合适的呢? zRam大小的配置比较灵活, 如果zRam配置过大, 后台缓存了应用过多, 这也是有可能会影响前台应用使用的流畅度。另外, zRam配置越大, 也需要关注系统的内存碎片化情。因此zRam并不是配置越大越好,具体的大小需要根据内存总大小及系统负载情况考虑及实测而定。
使用zRam,可能会存在低内存场景由于频繁的内存压缩导致kswapd进程占CPU高, 怎样改善? zRam本质就是以时间换空间, 在低内存的情况下, 肯定会比较频繁地回收内存, 这时kswapd进程是比较活跃的, 再加上通过压缩内存, 会更加消耗CPU资源。改善这种情况方法也比较多, 比如, 可以使用更优的压缩算法, 区别使用场景, 后台不影响用户使用的场景异步进行深度内存压缩, 与用户体验相关的场景同步适当减少内存压缩, 通过增加文件页的回收比例加快内存回收等等。
增大了zRam配置,对系统内存碎片是否有影响? 使用zRam是有可能导致系统内存碎片变得更严重的, 特别是zsmalloc分配不支持可移动内存类型的时候。新版的内核zsmalloc已经支持可移动类型分配的，但由于增大了zRam,结合android手机的使用特点, 仍然会有可能导致系统内存碎片较严重的情况,因些内存碎片问题也是需要重点关注的。解决系统内存碎片的方法也比较多, 可以结合具体的原因及场景进行优化。

参考资料

Linux内存压缩浅析之原理

zRAM内存压缩技术原理与应用

DDE v23 beta3 发布说明

DDE 桌面环境小组 — Sun, 28 Jan 2024 06:00:00 +0000

deepin v23 beta3 将于 2024 年 1 月 31 日发布（注：因存在部分临时设计变动，延期发布，仍计划在当周发布），这里为大家简要描述本次更新中，DDE 所涉及的变更，以及我们的进一步计划。另需注意，本文章倾向于对 DDE 项目整体的技术内容进行描述，面向 DDE 开发者和对 DDE 开发感兴趣的读者，并非面向最终用户的特性概览文章。

变化较大的默认组件

相比 deepin v23 beta2 而言，在于 deepin v23 beta3 发布的 DDE 中，有两个项目得到了较大规模的重构，并随 beta3 默认提供给各位用户。这两个项目分别是：

dde-application-manager (>= 1.2)
dde-launchpad (取代 dde-launcher)

dde-application-manager 承载了 DDE 下应用程序的启动与管理等职责，在早期版本中存在诸多架构不合理以及实现问题，影响到了 dde-launcher、dde-dock、dde-grand-search 等项目启动应用与管理应用功能的正常使用。于是我们对 dde-application-manager 进行了大规模的重构，也重新设计了此项目的对外 D-Bus 接口。在 beta3 中，你将不再会遇到类如应用频繁集体闪退的问题，对应用 desktop 文件的支持变得更加完整。在未来，也会对实时调整应用缩放等功能预留支持的空间。

dde-launchpad 则是对 dde-launcher 的完整重写。一方面，dde-launcher 对旧的 dde-application-manager 具有很高的偶合度，另一方面，旧的 dde-launcher 架构使得维护此组件变得非常困难。dde-launchpad 是目前 DDE 的首个基于 QML 的组件，且基于最新的 Qt 6。得益于 QML 技术，launchpad 将会有效利用 GPU 绘制界面，使交互体验更加流畅。不过由于 dde-launchpad 是完全重写版本，故尚有部分功能未在当前的 dde-launchpad 中提供。

技术预览组件

非技术用户请慎重启用技术预览功能

deepin v23 beta2 时，我们提供了一个需要用户手动安装的 dcc-insider-plugin 插件，称为技术预览插件。这个组件旨在帮助用户方便的测试 deepin 未来版本中计划提供但仍不稳定的系统组件。在 beta2 时，技术预览组件仅包含了 dde-launchpad 一项。而在 beta3 中，dde-launchpad 走出了技术预览阶段，而有更多的组件进入了技术预览阶段：

treeland
dde-shell
deepin-im

treeland 是 deepin 的下一代 wayland 窗口合成器，且可以同时提供会话管理功能。由于 treeland 会替换 deepin-kwin 并同样会接管 lightdm，故切换 treeland 时需要格外留意。

切换到 treeland 后，将会进入的 DDE 会话也会与原本有差异。treeland 会话中会使用 dde-shell 而非原本的 dde-dock、dde-widgets 等组件。尽管 dde-shell 可以独立使用，但目前 dde-shell 是作为与 treeland 共同配合进入技术预览阶段的桌面组件。dde-shell 提供了与 wayland 会话下的桌面环境的相关功能集成，今后的 dock 等组件也均会作为 dde-shell 的插件存在，以便提供更深度的集成。

deepin-im 是新的输入法组件，作为目前各种底层输入法框架的抽象层存在，以便用户更方便的管理输入法而无需关注底层的配置细节。deepin-im 并不与 treeland 绑定，可以单独启用。

后续计划

在未来，首要计划即使 dde-shell 可以走出技术预览阶段并配合 treeland 达成真正稳定可用的 wayland 会话，这意味着 treeland 与 dde-shell 相关的项目还有比较多的相关工作需要持续进行。也是我们的主要努力方向。另外，尽管 dde-shell 相关的 API 可能仍会存在一些变动，但我们计划在随后提供一些必要的文档来帮助开发者更好的了解 dde-shell 的目的与作用，以便帮助开发者参与到项目之中来。如果你对这相关的话题感兴趣，欢迎加入 DDE SIG 的 Matrix 群聊 (#dde:matrix.org) 之中来。

另外，由于 DDE 在 beta2 与 beta3 的变化较大，我们也计划提供一篇移植注意事项博客。笔者也是 DDE 移植 SIG 的成员，于是对应的文章计划会发布到 DDE 移植小组。如果您感兴趣，请考虑订阅 <planet.deepin.org> 的 RSS 更新。如果你本身在参与 DDE 的移植工作，那么也欢迎你加入 DDE 移植小组（#dde-port:deepin.org 或 https://t.me/ddeport）。

最后，感谢你读到这里。如有任何问题，欢迎在我们的开发者群（#deepin-community:deepin.org）进行讨论。

TLP 电源管理简述

deepin 社区官方博客 — Thu, 07 Dec 2023 00:00:00 +0000

简述

在上一篇浅析Linux电源配置之后，我们一直在深入探索如何进一步优化我们系统的续航和性能表现，今天它来了：

TLP 是适用于 Linux 的功能丰富的命令行实用程序，无需深入研究技术细节即可节省笔记本电脑电池电量。之前我们的系统使用的laptopmode,但是相较于TLP还有有部分劣势：比如tlp脚本是被动唤醒，可以以较小的开销完成电源管理相关内容。而且TLP文档支持非常完善，所以可以方便用户自行调整相关配置。以下是TLP官方文档内容的和我自己的理解的结合，各位系统用户可以结合自己的实际情况diy自己的电源策略文件，也可以将好的电源配置在deepin 论坛中分享。

工作原理

TLP 基本上所做的是调整影响功耗的内核设置，内核态的配置文件存储在RAM中，所以并不具备持久性。TLP将配置存储在用户态中，在内核启动时对其进行配置
TLP 处理的大多数内核设置都作为 sysfs 节点导出到用户空间，即 /sys/ 下的文件。tlp-stat 的输出将显示路径。
TLP 提供两组独立的设置，称为配置文件，一组用于电池（BAT），另一组用于交流操作。这意味着 TLP 不仅在启动时，而且在每次电源更改时都必须应用适当的配置文件（可以据此实现AC BT切换电源调度状态）

TLP触发事件（信号）

充电器插入（交流供电）：应用AC配置文件
充电器已拔下（电池供电）：应用BAT配置文件
已插入 USB 设备：激活设备的 USB 自动挂起模式（可以在配置文件设置例外或拒绝连接）
系统启动（boot）：应用与当前电源 AC/BAT 相对应的设置配置文件。应用充电阈值并根据您的个人设置切换蓝牙、Wi-Fi 和 WWAN 设备（在默认配置中禁用）
系统关机 (power off)：保存或切换蓝牙、Wi-Fi 和 WWAN 设备状态，并根据您的个人设置禁用 USB 自动挂起（在默认配置中禁用）
系统重启：相当于关机再启动
系统挂起到 ACPI 睡眠状态 S0ix（空闲待机）、S3（挂起到 RAM）或 S4（挂起到磁盘）：保存蓝牙、Wi-Fi 和 WWAN 设备状态，并根据您的个人设置关闭可移动光盘驱动器的电源（在默认配置中禁用）。
系统从 ACPI 睡眠状态 S0ix（空闲待机）、S3（挂起到 RAM）或 S4（挂起到磁盘）恢复：应用与当前电源 AC/BAT 相对应的设置配置文件。恢复充电阈值以及蓝牙、Wi-Fi 和 WWAN 设备状态，具体取决于您的个人设置（在默认配置中禁用）。
LAN、Wi-Fi、WWAN 连接/断开连接或笔记本电脑插接/未插接：根据您的个人设置启用或禁用内置蓝牙、Wi-Fi 和 WWAN 设备（在默认配置中禁用）

除了上述事件之外，TLP 不会对设置进行动态或自适应更改特别是，TLP 绝不会因 CPU 负载、电池电量或其他原因而调整设置（如果我们需要去实现这一部分，则可以，则可以通过添加一个信号的方式来实现）

安装

sudo apt install tlp

使用

启动

安装后TLP将在系统启动的时候自动启动，如果你不想重启系统，可以使用sudo tlp start来启动tlp，也可以使用此命令来应用更改。

状态

tlp-stat -s TLP是bash脚本，所以不存于daemon进程

命令行

TLP：

sudo tlp bat 应用电池配置文件并进入手动模式手动模式意味着对电源的更改将被忽略，直到下一次重新启动或发出 tlp start 以恢复自动模式

sudo tlp ac应用交流配置文件并进入手动模式

sudo tlp usb 对所有的ubs设备应用自动挂起

sudo tlp bayoff 关闭 MediaBay/Ultrabay 中的光驱电源

sudo tlp setcharge [<START_CHARGE_THRESH> <STOP_CHARGE_THRESH>] [BAT0|BAT1|BAT<x>|CMB0|CMB1] 可以设定对指定电池开始充电百分比和结束充电的百分比，以达到养护电池的目的（如果不带参数会重置电池管理方案）（命令只能暂时更改，如果需要持久化更改需要修改配置文件）

sudo tlp fullcharge [BAT0|BAT1|BAT<x>|CMB0|CMB1] 设定电池充满

tlp diskid 显示已经配置驱动器的磁盘ID

以下部分为ThinkPad专属

sudo tlp chargeonce [BAT0|BAT1] 将电池充电至停止充电阈值一次，这个阈值是使用setcharge设置的

sudo tlp discharge [BAT0|BAT1] 让电池在交流电源下完全放电

sudo tlp recalibrate [BAT0|BAT1]校准电池

TLP-RDW

sudo tlp-rdw [ enable | disable ] 启用或关闭无线电管理功能

bluetooth [ on | off | toggle ]
nfc [ on | off | toggle ]
wifi [ on | off | toggle ]
wwan [ on | off | toggle ]

启用、禁用、切换或检查内置蓝牙、NFC、Wi-Fi 和 WWAN（3G/UMTS、4G/LTE 或 5G）无线电的状态，如果不带参数则为当前硬件状态（硬件需要支持rfkill）

TLP-STAT

sudo tlp-stat 查看TLP配置信息，系统信息和内核省电设置以及电池数据

sudo tlp-stat [-b /--battery] 查看电池信息，部分电池加-v参数可以查看电压

sudo tlp-stat [-c /--config]查看配置信息

sudo tlp-stat --cdiff 查看默认配置和用户配置之间的差异

sudo tlp-stat [-d /--disk] 查看硬盘配置信息

sudo tlp-stat [-e/ --pcie] 查看Pcie配置信息

配置

TLP最重要的就是其配置文件，可以说，TLP是否节电的关键。 TLP 使用两个根据电源自动应用的设置配置文件：

以_AC结尾的参数在连接交流电源的时候生效
以_BAT结尾的参数在使用电池的时候有效
既不以 _AC 结尾也不以 _BAT 结尾的参数适用于这两个配置文件

配置文件

按指定顺序从以下文件中读取设置：

Intrinsic defaults 固有默认值（这个配置为TLP自带，不可被更改）
/etc/tlp.d/*.conf：插入式自定义片段，按词法（字母顺序）顺序读取，不过建议可以使用一般配置命名方法（00_xxxx.conf)
/etc/tlp.conf：用户配置

如果多个参数相同，但在同一文件中也存在相同的参数，则最后一个匹配项优先，这也意味着，/etc/tlp.conf 中的参数将覆盖其他任何内容，因为它是最后读取的默认的/etc/tlp.conf 中的所有参数都被禁用，删除前导 # 以激活您的更改 /etc/tlp.d/ 目录中的配置文件由用户创建： * 文件名必须以 .conf 结尾，否则文件将被忽略 * 00-template.conf 作为示例提供

参数默认值

配置中有两种参数，一种是具有默认值的，会在本文档中说明，并且在/etc/tlp.conf中有Default前缀。还有一种没有默认值的。

参数语法

配置文件由参数和注释行组成。

参数行

PARAMETER=value

如果value包含空格，则需要使用双引号

key="111 1111 1111"

注释行

以#开头，在1.6版本后可以在参数行后接#作为注释

禁用功能

没有默认值：使用注释或者删除即可
有默认值：赋空值即可 eg：key=""

使用`+=`追加配置

和bash的环境变量一样，支持使用+=作为追加配置

使用root权限编辑配置文件，在保存更改后可以使用重启，拔插ac电源或者使用sudo tlp start命令激活配置

配置详解

基础操作

参数名称	默认参数值	描述
TLP_ENABLE	1	设置为0可禁用TLP（需要重新启动）。未配置时的默认值：1
TLP_WARN_LEVEL	/	控制如何发出有关无效设置的警告： 0 - 禁用 1 - 向系统日志/日志报告后台任务（启动、恢复、电源更改） 2 - 外壳命令向终端报告（标准） 3 - 1和2的组合。未配置时的默认值：3
TLP_DEFAULT_MODE	/	定义TLP的默认操作模式（AC或BAT），以防无法检测到电源。仅涉及某些台式机和嵌入式硬件。
TLP_PERSISTENT_DEFAULT	0	选择如何确定操作模式： 0 – 根据实际电源应用设置配置文件（默认） 1 – 始终使用TLP_DEFAULT_MODE设置。未配置时的默认值：0
TLP_PS_IGNORE	/	确定工作模式时要忽略的电源等级：（用作错误检测到操作模式 AC 或 BAT 的笔记本电脑的解决方法） AC BAT USB - 仅限版本 1.4 及更高版本。仅限版本 1.4 及更高版本：输入多个类，以空格分隔。

音频

参数名称	默认参数值	描述
SOUND_POWER_SAVE_ON_AC/BAT	1	设置为0可禁用音频省电模式（需要重新启动）。未配置时的默认值：1（AC），1（BAT）- 版本 1.4 及更高版本，0（AC），1（BAT）- 版本 1.3。
SOUND_POWER_SAVE_CONTROLLER	Y	Y – 关闭控制器和声音芯片的电源 N – 控制器保持活动状态。未配置时的默认值：Y。

注释： SOUND_POWER_SAVE_ON_AC/BAT 指的是SOUND_POWER_SAVE_ON_AC 和 SOUND_POWER_SAVE_ON_BAT

电池保养

参数名称	参数值	描述
START_CHARGE_THRESH_BAT<x>	75	电池充电水平低于该水平，连接充电器时将开始充电。
STOP_CHARGE_THRESH_BAT<x>	80	电池充电水平，超过该水平，充电器连接时充电将停止。

这些参数用于设置笔记本电脑主/内部电池（BAT0）和辅助电池（BAT1）的充电阈值。启动充电阈值表示在连接充电器时，电池充电水平低于该值时将开始充电。停止充电阈值表示在充电器连接时，电池充电水平超过该值时将停止充电。这些阈值始终具有较低的可用电池容量，因此默认情况下禁用这些设置，并且必须通过删除前导 # 来显式启用这些设置。

光驱

参数名称	默认参数值	描述
BAY_POWEROFF_ON_AC/BAT	0	控制光驱在交流电源和电池供电时是否关闭电源。 1：保持光驱开启状态 0：关闭光驱电源
BAY_DEVICE	sr0	指定光驱设备。

硬盘

参数名称	默认参数值	描述
DISK_DEVICES	“nvme0n1 sda”	定义参数作用的磁盘设备。多个设备用空白分隔。
DISK_APM_LEVEL_ON_AC/BAT	“254 254”（AC） “128 128” (BAT)	设置“高级电源管理级别”。可能的值介于1和255之间。 1 – 最大省电/最低性能 – 重要提示：此设置可能会导致磁盘驱动器磨损增加，因为读写磁头卸载过多 128 – 省电和磨损之间的折衷（电池的 TLP 标准设置） 192 – 防止某些 HDD 的磁头过度卸载 254 – 最小省电/最大性能（交流电的 TLP 标准设置） 255 – 禁用 APM（某些磁盘型号不支持） keep – 用于跳过特定磁盘的此设置的特殊值（同义词：`_`）
DISK_APM_CLASS_DENYLIST	“usb ieee1394”	从高级电源管理（APM）中排除磁盘类。可能的值：sata、ata、usb、ieee1394。默认为“usb ieee1394”。
DISK_SPINDOWN_TIMEOUT_ON_AC/BAT	“0 0”	磁盘空闲时主轴电机停止的超时值。有效设置：0（已禁用）、1..240（5秒到20分钟）、241..251（30分钟到5.5小时）。
DISK_IOSCHED	“keep keep”	两个参数为多队列（blk-mq）调度器：`mq-deadline` 、`none`、`kyber`、`bfq`、`keep` 单队列调度程序：`deadline`、`cfq`、`bfq`、`noop`、`keep` 如果未配置，默认情况下所有磁盘将使用内核的默认调度程序。
SATA_LINKPWR_ON_AC/BAT	“med_power_with_dipm”	设置SATA链路的电源管理模式。可能的值包括：max_performance、medium_power、med_power_with_dipm、min_power。默认为med_power_with_dipm。
SATA_LINKPWR_DENYLIST	“host1”	从AHCI链路电源管理（ALPM）中排除SATA磁盘的主机列表。默认为空。
AHCI_RUNTIME_PM_ON_AC	“on”	控制NVMe、SATA、ATA和USB磁盘以及SATA端口的运行时电源管理。可能的值包括：auto（启用）、on（禁用）
AHCI_RUNTIME_PM_ON_BAT	“auto”	同上
AHCI_RUNTIME_PM_TIMEOUT	15	磁盘或端口挂起前的不活动时间（秒）。仅在激活AHCI_RUNTIME_PM_ON_AC/BAT时有效。默认为15。

注释：DISK_IOSCHED 如果使用是NVME设备时，最好使用无IO调度程序来减少CPU开销（none和noop）

文件系统

参数名称	默认参数值	描述
DISK_IDLE_SECS_ON_AC/BAT	0 (AC), 2 (battery)	笔记本电脑模式等待磁盘空闲的秒数，然后再次将脏缓存块从 RAM 同步到磁盘。值大于0将激活内核笔记本电脑模式。请勿更改此设置。
MAX_LOST_WORK_SECS_ON_AC/BAT	15 (AC), 60 (battery)	将文件系统缓冲区中未保存的数据写入磁盘的超时时间（秒）。

图形显卡

参数名称	默认参数值	描述
INTEL_GPU_MIN_FREQ_ON_AC/BAT	0	设置 Intel GPU 的最小频率。可能的值取决于硬件。通过运行 `tlp-stat -g` 命令查看可用频率。
INTEL_GPU_MAX_FREQ_ON_AC/BAT	0	设置 Intel GPU 的最大频率。可能的值取决于硬件。通过运行 `tlp-stat -g`命令查看可用频率。
INTEL_GPU_BOOST_FREQ_ON_AC/BAT	0	设置 Intel GPU 的睿频频率。可能的值取决于硬件。通过运行 `tlp-stat -g` 命令查看可用频率。
RADEON_DPM_PERF_LEVEL_ON_AC/BAT	auto	控制 AMD GPU 的动态电源管理（DPM）性能级别。支持 amdgpu（仅限 TLP 版本 1.4 及更高版本）和 radeon 驱动程序。可能的值包括 auto、low、high。默认值：auto。
RADEON_DPM_STATE_ON_AC/BAT	performance (AC), battery (BAT)	控制 AMD GPU 的电源管理方法。可能的值包括 battery、balanced、performance。默认值：performance（AC）、battery（BAT）。
RADEON_POWER_PROFILE_ON_AC/BAT	default	控制 AMD GPU 的时钟。仅在旧版 ATI 硬件上受 radeon 驱动程序支持（DPM 不可用）。可能的值包括 low、mid、high、auto、default。默认值：default。

这些参数允许用户调整 Intel GPU 和 AMD GPU 在交流电和电池模式下的性能和电源管理行为。在配置这些参数时，建议参考硬件规格和运行 tlp-stat -g 查看可用频率。

kernel

参数名称	默认参数值	描述
NMI_WATCHDOG	0	激活内核 NMI 看门狗定时器。设置为 0 表示禁用，有助于节省电源。设置为 1 表示启用，对于内核调试和看门狗守护程序是相关的。

不建议关闭watchdog 否则可能导致内核崩溃后无法自动重启和内核调试

网络

参数名称	默认参数值	描述
WIFI_PWR_ON_AC/BAT	off (AC),	设置 Wi-Fi 的电源保存模式。可能的值包括 off（禁用）和 on（启用）。默认值：off（AC）、on（BAT）。
	on (BAT)	提示：支持已弃用的配置值 1=off/5=on，以实现向后兼容性。
WOL_DISABLE	Y	控制是否禁用 Wake-on-LAN（LAN 唤醒）。可能的值包括 Y（禁用）和 N（不禁用，保持 BIOS 默认）。默认值：Y。注意：更改为 WOL_DISABLE=N 后，需要重新启动才能使新设置生效（或在 shell 中使用 `sudo ethtool -s wol g`）。

这些参数允许用户配置Wi-Fi的电源保存模式和控制Wake-on-LAN（LAN唤醒）功能。

平台

参数名称	默认参数值	描述
PLATFORM_PROFILE_ON_AC/BAT	performance	选择平台配置文件以控制系统的功率/性能级别、散热和风扇速度的运行特性。可能的值包括 performance、balanced、low-power。默认值：performance（AC）、low-power（BAT）。
MEM_SLEEP_ON_AC/BAT	s2idle	选择系统挂起模式。可能的值包括 s2idle（空闲待机）和 deep（挂起到 RAM）。注意：更改挂起模式可能导致系统不稳定和数据丢失。请使用 tlp-stat -s 检查系统上不同模式的可用性。如果不确定，请坚持使用系统默认值。

其实如果能使用S3休眠那就更好，不过现在很多厂商并不支持S3,所以如果能用S2那就用S2吧。

处理器

参数名称	默认参数值	描述
CPU_DRIVER_OPMODE_ON_AC/BAT	active (amd-pstate), active (intel_pstate)	选择 CPU 缩放驱动程序操作模式。配置取决于活动驱动程序：对于 amd-pstate（Active 模式），可能的值为 active 和 passive；对于 intel_pstate（Active 模式），可能的值为 active、passive 和 guided。
CPU_SCALING_GOVERNOR_ON_AC/BAT	powersave	选择用于自动频率缩放的 CPU 缩放调节器。配置取决于活动驱动程序。可能的值包括 performance、powersave、conservative、ondemand、userspace 和 schedutil。默认值：powersave（AC）、powersave（BAT）。
CPU_SCALING_MIN/MAX_FREQ_ON_AC/BAT	0, 9999999	设置可用于缩放调控器的最小/最大频率。可能的值取决于您的 CPU。请查阅`tlp-stat -p`的输出以获取可用频率。
CPU_ENERGY_PERF_POLICY_ON_AC/BAT	balance_performance	设置 CPU 能耗/性能策略。可能的值包括 performance、balance_performance、default、balance_power 和 power。默认值：balance_performance（AC）、balance_power（BAT）。
CPU_MIN/MAX_PERF_ON_AC/BAT	0, 100	定义 Intel CPU 的最小/最大 P 状态，表示为总可用处理器性能的百分比。建议仅用于限制 CPU 的功耗。可能的值在 0 到 100 之间。默认值：0 到 100（AC）、0 到 30（BAT）。
CPU_BOOST_ON_AC/BAT	1	配置 CPU “turbo boost”（Intel）或“turbo core”（AMD）功能。可能的值为 0（禁用）和 1（允许）。请注意，值为 1 不会激活提升，只是允许它。默认值：1（AC）、0（BAT）。
CPU_HWP_DYN_BOOST_ON_AC/BAT	1	配置 Intel CPU HWP 动态提升功能。可能的值为 0（禁用）和 1（启用）。要求 Intel Core i 第 6 代（“Skylake”）或更新的 CPU，在活动模式下具有 intel_pstate 扩展驱动程序。默认值：1（AC）、0（BAT）。

这些参数允许用户配置 CPU 的性能和功耗特性，包括缩放驱动程序操作模式、调节器、频率范围、能耗/性能策略、P 状态范围、提升功能以及 HWP 动态提升功能。

部分电脑的BIOS会干预PState 所以需要检查自己的CPU是否支持

无线设备

参数名称	默认参数值	描述
RESTORE_DEVICE_STATE_ON_STARTUP	0	在启动时从上次关机中恢复无线电设备状态。可能的值为 0（禁用）和 1（启用）。默认值：0。
DEVICES_TO_DISABLE_ON_STARTUP	""	在启动时禁用内置无线电设备。可能的值包括 bluetooth、wifi 和 wwan，多个设备用空白分隔。
DEVICES_TO_ENABLE_ON_STARTUP	""	在启动时启用内置无线电设备。可能的值与上述相同，用于启用在默认情况下禁用的设备。
DEVICES_TO_ENABLE_ON_AC	""	插入交流电源时启用内置无线电设备。可能的值与上述相同。
DEVICES_TO_DISABLE_ON_BAT	""	在更改为电池电源时禁用内置无线电设备，无论其连接状态如何。可能的值与上述相同。
DEVICES_TO_DISABLE_ON_BAT_NOT_IN_USE	""	在更改为电池电源时禁用未连接的内置无线电设备。可能的值与上述相同。

这些参数允许用户配置在系统启动、关闭或更改电源状态时如何处理内置的蓝牙、Wi-Fi 和 WWAN 设备。可通过设置禁用或启用这些设备，以及在何种条件下执行这些操作。

无线配置向导（自动化配置）

参数名称	参考参数值	描述
DEVICES_TO_DISABLE_ON_LAN_CONNECT	“wifi wwan”	当建立 LAN 连接时，禁用蓝牙、Wi-Fi 和 WWAN 设备。多个设备用空白分隔。
DEVICES_TO_DISABLE_ON_WIFI_CONNECT	“wwan”	当建立 Wi-Fi 连接时，禁用 WWAN 设备。
DEVICES_TO_DISABLE_ON_WWAN_CONNECT	“wifi”	当建立 WWAN 连接时，禁用 Wi-Fi 设备。
DEVICES_TO_ENABLE_ON_LAN_DISCONNECT	“wifi wwan”	当断开 LAN 连接时，启用蓝牙、Wi-Fi 和 WWAN 设备。多个设备用空白分隔。
DEVICES_TO_ENABLE_ON_WIFI_DISCONNECT	""	当断开 Wi-Fi 连接时，启用所有设备。
DEVICES_TO_ENABLE_ON_WWAN_DISCONNECT	""	当断开 WWAN 连接时，启用所有设备。
DEVICES_TO_ENABLE_ON_DOCK	""	在对接后，启用所有设备。
DEVICES_TO_DISABLE_ON_DOCK	""	在对接后，禁用所有设备。
DEVICES_TO_ENABLE_ON_UNDOCK	“wifi”	在取消对接后，启用 Wi-Fi 设备。
DEVICES_TO_DISABLE_ON_UNDOCK	""	在取消对接后，禁用所有设备。

这些参数允许用户配置在特定事件触发时如何处理内置的蓝牙、Wi-Fi 和 WWAN 设备。用户可以根据 LAN、Wi-Fi 或 WWAN 的连接状态、对接或取消对接等事件来启用或禁用这些设备。

PCIE电源配置

参数名称	默认参数值	描述
RUNTIME_PM_ON_AC	on	控制 PCIe 设备的运行时电源管理。可能的值：auto（启用）或 on（禁用）。未配置时的默认值：on（AC）。
RUNTIME_PM_ON_BAT	auto	控制 PCIe 设备的运行时电源管理。可能的值：auto（启用）或 on（禁用）。未配置时的默认值： auto（BAT）。
RUNTIME_PM_DENYLIST	""	从运行时电源管理中排除列出的 PCIe 设备地址。使用 lspci 查找地址。
RUNTIME_PM_DRIVER_DENYLIST	“mei_me nouveau radeon”	从运行时电源管理中排除分配给所列驱动程序的 PCIe 设备。使用 tlp-stat -e 查找驱动程序。
RUNTIME_PM_ENABLE	""	为列表中的 PCI（e）设备地址永久启用（自动）运行时 PM。这优先于所有先前的运行时 PM 设置。使用 lspci 获取地址。
RUNTIME_PM_DISABLE	""	为列表中的 PCI（e）设备地址永久禁用（on）运行时 PM。与 RUNTIME_PM_ENABLE 类似，不过是禁用。使用 lspci 获取地址。
PCIE_ASPM_ON_AC	default	设置 PCIe ASPM 省电模式。可能的值：default（推荐）、performance（性能）、powersave（省电）和 powersupersave（PowerSuperSave，超级省电）。未配置时的默认值：default。
PCIE_ASPM_ON_BAT	default	设置 PCIe ASPM 省电模式。可能的值：default（推荐）、performance（性能）、powersave（省电）和 powersupersave（PowerSuperSave，超级省电）。未配置时的默认值：default。

这些参数允许用户配置与 PCIe 设备相关的运行时电源管理和 ASPM 等功能。用户可以根据电源来源、设备地址、驱动程序等来调整这些设置，以实现更好的功耗管理。（建议不要对nvidia驱动进行调整，可能会引发意外）

USB

参数名称	默认参数值	描述
USB_AUTOSUSPEND	1	在启动时和插入时为 USB 设备设置自动挂起模式。可能的值：1（启用）或 0（禁用）。未配置时的默认值：1。
USB_DENYLIST	""	从自动挂起模式中排除 USB 设备 ID。使用 tlp-stat -u 查找 ID。多个 ID 用空格分隔。
USB_EXCLUDE_AUDIO	1	从自动挂起模式中排除音频设备：1（排除）或 0（不排除）。未配置时的默认值：1。
USB_EXCLUDE_BTUSB	0	从自动挂起模式中排除蓝牙设备：1（排除）或 0（不排除）。未配置时的默认值：0。
USB_EXCLUDE_PHONE	0	将智能手机从自动挂起模式中排除以启用充电：1（排除）或 0（不排除）。未配置时的默认值：0。
USB_EXCLUDE_PRINTER	1	从自动挂起模式中排除打印机：1（排除）或 0（不排除）。未配置时的默认值：1。
USB_EXCLUDE_WWAN	0	从自动挂起模式中排除内置 WWAN 设备：1（排除）或 0（不排除）。未配置时的默认值：0。
USB_ALLOWLIST	""	为已被上述任何设置排除的 USB 设备 ID 重新启用自动挂起模式。使用 `tlp-stat -u` 查找 ID。多个 ID 用空格分隔。
USB_AUTOSUSPEND_DISABLE_ON_SHUTDOWN	0	在系统关闭时禁用 USB 自动挂起模式：1（启用）或 0（禁用）。未配置时的默认值：0。

Trace Mode

TLP_DEBUG="arg bat disk lock nm path pm ps rf run sysfs udev usb"

结语

我们对于系统的优化不仅于此，现阶段tlp的配置策略仅对于部分有能力的用户公开，后续经过充分的测试和调优之后，会提供几份默认的配置给普通用户使用。并将来将这些配置文件GUI化，集成于深度定制项目中，为用户提供更为方便直观的操作体验。

从这一阶段对于电源优化的探索可以看出，deepin系统的电源管理方案优化不仅是为了解决用户反馈的问题，更是一种对用户需求的回应和尊重。在未来，deepin系统将继续秉持用户至上的原则，不断提升系统的性能和用户体验，为广大用户提供更加优秀的操作系统产品。

关于 DDUC2023 和 QtWS23 分享内容的一些想法

deepin 社区官方博客 — Thu, 30 Nov 2023 00:00:00 +0000

2023 年 11 月 21 日，Qt Group 在上海成功举办了“Qt 全球峰会 2023 中国站”，本次大会上发布了关于 Qt 开放框架与开发工具的战略，集中展示了最新的产品、解决方案，阐述了它们在优化软件跨平台开发全流程、提升研发团队跨职能协作效率以及加速产品迭代速度等方面的强大优势，同时大会上也分享了对于人工智能如何影响软件开发和测试的思考。

Qt 作为 Linux 上最重要的开发工具之一，为中国信创产业的发展和创新提供了更多的可能性和选择。Qt Group 中国区负责人许晟在开幕致辞中表示，“Qt 中国作为 Qt Group 在中国的本地化团队，不仅通过源代码交付帮助本地企业实现软件的自主创新，还基于强大的跨平台能力支持针对本地操作系统和主流芯片的开发，为中国信创产业的发展和创新提供了更多的可能性和选择。

值得一提的是，deepin 已为 Qt社区贡献 100000+ 行代码，在贡献者中名列前茅。此外，deepin 社区也基于 Qt 开发了一整套简单且实用的通用开发框架 Development ToolKit（简称DTK），DTK 处于deepin系统中的核心位置。DDE 中超过30+组件，如浏览器、音乐、邮件等40余款原生应用全部使用 DTK 开发。为此，deepin（深度）社区在 deepin 开发者平台上专门提供了在 deepin 上进行 Qt 开发的文档指导。

2023 年 11 月 18 日，deepin（深度）社区在北京798艺术中心举办了第十三届深度开发者与用户大会（Deepin Developer&User Conference，简称DDUC），在本次大会上，deepin社区也是公开了近一年在 DTK 和 Qt 这块的建设成果，目前 DTK 已正式适配 Qt6(6.4.2)，实现全面升级，相关介绍可以查看《deepin（深度）宣布 deepin DTK 已完成基于 Qt6 的全面升级！》。

在本次 QtWS23 峰会上，Qt Group 资深开发工程师齐亮介绍了Qt Wayland 的最新进展。近些年 Linux 桌面发行版迁移到 Wayland 的趋势愈发明显，大有替代 X11 之势。Ubuntu 目前已经默认 Wayland 会话，GNOME 在 Wayland 支持这块一直走在 Linux 发行版的前列，且动作非常激进，目前 GNOME 桌面已经对外宣布将移除对 X.Org 会话支持，默认使用 Wayland。X11 诞生于 1984 年，其设计符合当时的硬件环境、用户需求。随着技术的发展，出现了很多问题，特别是在桌面环境里面，需要 Xorg、窗口管理器、桌面环境组件三者之间进行复杂的交互、协作，导致演进困难。同时 X11 对于新特性的支持较差，Hi-DPI 体验糟糕，并且完全不支持 HDR。

事实上，在 2023 年5 月 17 日，deepin（深度）社区在推出 deepin V23 Beta 版的同时也已经支持了 Wayland 桌面环境。在 V23 beta 版本中，DDE 试验性的开启了 Wayland 的支持，允许用户在 Wayland 协议下的桌面工作环境启动。在 deepin V23 中支持 Wayland，是 DDE 的一个非常重要的特性，也是今后 deepin 团队的工作重点，以实现 X11 版本的完全替代，提升 DDE 的优质体验，在 Wayland 桌面环境领域达到领先水平。

DDE（deepin desktop environment）是deepin（深度）社区自主开发的美观易用、极简操作的桌面环境，主要由桌面、启动器、任务栏、控制中心、窗口管理器等组成，系统中预装了深度特色应用，它既能让您体验到丰富多彩的娱乐生活，也可以满足您的日常工作需要。

在此背景下，deepin 团队在今年 DDUC 大会了宣布将推出 Treeland 作为今后 DDE 所有功能开发的核心。Treeland 的底层基于 wlroots，并与 Qt Quick 进行了绑定，可同时兼顾两者的优点，wlroots 是 Wayland 生态中发展最迅速的开发库之一，具有功能丰富、演进速度快等优势，将其与 Qt Quick 结合则可以弥补 wlroots 在 GUI 能力方面的欠缺，极大的降低 Wayland 合成器的开发难度，实现 Vulkan、OpenGL ES2、软件渲染等多种渲染方式的无缝切换。

DDE 的新架构，将桌面环境各技术领域的组件进行了统一设计，允许桌面环境开发人员对其进行完全掌控，可轻松实现设备共享、多端无缝协同等高级功能。

未来，deepin（深度）社区将继续与最新技术保持同步，持续推进 DTK 的改进优化，也期待更多感兴趣的朋友加入到 deepin 开源社区中来，讨论更多内容，为推动生态发展贡献力量。

deepin 5g wwan 支持

deepin 社区官方博客 — Wed, 08 Nov 2023 00:00:00 +0000

本文简述了deepin v23系统使用5G WWAN网卡连接互联网的方式，仅仅作为一个临时解决方案和技术验证使用，后期会在系统中内置此功能。

第一步：安装modemmanager

modemmanager是一个由freedesktop托管的项目，旨在在linux设备上运行调制解调器以让linux设备获得蜂窝无线网络连接的能力，所以我们第一步骤就是安装此软件。目前deepin已经支持此软件最新版本：

sudo apt install modemmanager

同时，你需要确保你的内核模块已经正确加载了你的WWAN驱动，你可以通过使用lspci -vvv查看详细信息

在安装了modemmanager后，你可以通过mmcli 命令使用命令行与其交互，使用mmcli —help-all来获取全部的帮助选项。

第二步：使用mmcli连接5G网络

使用mmcli -L 获取你的wwan卡信息，返回的信息有三个内容，分别为：DBus地址、设备类型、设备ID，其中DBus地址的最后一位为设备编号，你可以使用mmcli --modem=<设备编号>的方式查看设备详细支持信息。

如果你的SIM卡设置了PIN锁，则需要在连接网络之前使用mmcli --modem=0 --sim=0 --pin=**** 的方式连接，而后我们就可以启动相关设备了：

mmcli --modem=<设备编号> --enable

然后你需要使用simple connect连接网络

mmcli -m <设备编号> --simple-connect='apn=<apn名>,ip-type=ipv4v6'

比如我的连接方式为

mmcli -m 4 --simple-connect='apn=ctnet,ip-type=ipv4v6'

此时你再使用mmcli -m <设备编号> 查看信息的时候可以查看Bearer的信息，Bearer的DBus的最后一位为其编号。使用命令查看Bearer的信息：

mmcli -m <设备编号> -b <Bearer编号>

如果你看到Bearer相关信息，就几乎接近成功了：

 ------------------------------------
General | path: /org/freedesktop/ModemManager1/Bearer/0
| type: default
------------------------------------
Status | connected: yes
| suspended: no
| multiplexed: no
| interface: wwan0
| ip timeout: 20
------------------------------------
Properties | apn: ctnet
| roaming: allowed
| ip type: ipv4
| allowed-auth: none, pap, chap, mschap, mschapv2, eap
| user: ctnet@mycdma.cn
| password: vnet.mobi
------------------------------------
IPv4 configuration | method: static
| address: 10.122.58.19
| prefix: 8
| gateway: 10.122.58.17
| dns: 202.103.24.68, 202.103.44.150
| mtu: 1420
------------------------------------
Statistics | start date: 2023-11-07T05:40:08Z
| duration: 1260
| uplink-speed: 1250000000
| downlink-speed: 4670000000
| attempts: 1
| total-duration: 1260

第三步：使用nmcli打开连接

networkmanager对mm是有做支持，在你完成上述步骤之后，可以通过ip a命令查看，可以看到一个被down掉的接口，我们使用nmcli查看其详细信息：

nmcli device show

你就可以看到一个以wwan开头的设备：

GENERAL.DEVICE: wwan0mbim0
GENERAL.TYPE: gsm
GENERAL.HWADDR: （未知）
GENERAL.MTU: 1420
GENERAL.STATE: 100（已连接）
GENERAL.CONNECTION: wwan0mbim0
GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/3
IP4.ADDRESS[1]: 10.122.58.19/8
IP4.GATEWAY: 10.122.58.17
IP4.ROUTE[1]: dst = 10.0.0.0/8, nh = 0.0.0.0, mt = 700
IP4.ROUTE[2]: dst = 0.0.0.0/0, nh = 10.122.58.17, mt = 700
IP4.DNS[1]: 202.103.24.68
IP4.DNS[2]: 202.103.44.150
IP6.GATEWAY: --

使用下述命令打开此设备

nmcli d connect <设备名>

上述设备名就是以wwan开头的设备

然后你就可以使用5G网络连接了

xtrace

deepin 社区官方博客 — Sat, 04 Nov 2023 02:19:31 +0000

介绍

xtrace是一个用于跟踪分析X11图形协议通信的工具,它可以监控和记录X11服务器上的各种场景,以帮助开发人员诊断和调试与图形界面相关的问题。作为一款强大的工具，xtrace可用于逆向工程、调试分析、性能分析等领域。在Linux X11系统中，xtrace能够记录一个程序在运行时所发起的X11协议请求和XServer发送给程序的事件，以及这些调用的参数。这对于在不阅读源码情况排查程序中的问题、理解程序行为、分析性能瓶颈以及进行协议审计都非常有用。笔者在工作过程中使用该工具深度剖析过腾讯会议、simplescreenrecorder等应用程序的实现，在没有阅读代码的前提下可以获得软件录屏的工作流程，配合阅读常规的X11录屏代码，可分析出其部分工功能异常原因，这些经验在xwayland适配X11应用程序截图录屏项目中通过实战解决了一系列问题。

本文主要介绍的是X11协议的监视工具，希望您在读完本篇文章后可以对如何监控X11协议有比较深刻的认知，在工作中经常会碰到一些X11应用程序运行时功能异常，在没有应用程序源码的情况下通过xtrace进行调试是一个不错的选择，希望在阅读完这篇文章后，能丰富您的调试技巧。祝您阅读愉快！

xtrace的安装和使用非常简单，打开终端像如下输入命令即可启动工具：

// UOS上安装xtrace，deepin上没有可以在http://snapshot.debian.org/上下载
sudo apt install xtrace
// 运行之后协议电报内容会存储在/tmp/dde-calendar.xtrace中
xtrace -n -o /tmp/dde-calendar.xtrace dde-calendar

命令行选项	含义或用途
–display, -d	用于ssh远程调试，例如:xtrace -d :0 dde-calendar
–outfile, -o	用于将通信内容转存到磁盘，例如:xtrace -o /tmp/x.log dde-calendar
–stopwhendone, -s	进程退出后停止xtrace，例如:xtrace -s dde-calendar

工作原理

如图1所示，X11其主要有两种通信方式，在同一个计算机内主要使用unix domain socket进行通信；在不同计算机之间使用TCP/IP通信。只需要“截获”通信消息，将其转为易于读取的格式输出即可达到监控目的。这是xtrace工作的基本原理。

图1. 不同客户端使用同一个XServer显示器框架图

如下图2是X11窗口创建的基本流程，因为篇幅限制，图中只绘制了基础的请求和事件，但X11协议远比图中绘制的复杂，笔者在此只介绍一下基础的协议交互模型，方便在读者在查看xtrace追踪日志时有基础的认知。

图2. X11协议交互流程

总之xtrace是Xorg X Server自带的一个工具，通过分析xtrace的输出，你可以了解X Server是如何处理客户端应用程序的请求，以及可能的问题所在。xtrace 工具的作用：

调试X问题：如果你遇到了与图形界面相关的问题，例如窗口无法正常显示、图形卡驱动问题等，你可以使用xtrace来捕获X Server的活动，帮助你找出问题所在。
性能分析：xtrace可以记录X Server内部的操作，帮助你分析系统的图形性能，找出潜在的瓶颈。
理解X协议交互：X Server与客户端应用程序之间的通信是通过X协议进行的。xtrace可以捕获这些通信，帮助你理解应用程序与X Server之间的交互方式。
功能逆向：对于依赖X11协议的软件无法查看源码，可以通过观察通信协议，逆向其部分核心功能的实现请注意，xtrace的输出可能会非常详细，因此在使用时需要注意过滤和分析输出，以便关注于你感兴趣的信息。

X11在文件系统中暴露了通信用的socket套接字文件，这使得第三方应用程序可以监控套接字文件从而“窥视"X11客户端和服务端之间的通信，这一技术点是xtrace工作的主要基础。

// X11 socket套接字文件在文件系统中的位置
ls /tmp/.X11-unix
X0 X9

如下日志所示xtrace工作的本质就是不断地获取wrote和received的数据然后将其解析为易于阅读的描述语言打印出来。

// 全量日志
001:>:received 32 bytes
001:>:09dc:32: Reply to InternAtom: atom=0x250("_NET_KDE_COMPOSITE_TOGGLING")
001:>:wrote 32 bytes
001:>:received 32 bytes
001:>:09dc: Event XKEYBOARD-XkbEvent(85) type=2 time=0x018d8071 device=0x03 not-yet-supported=0x10,0x00,0x00,0x10,0x01,0x00,0x00,0x00,0x00,0x01,0x90,0x10,0x10,0x10,0x90,0x00,0x01,0x90,0x11,0x00,0x00,0x87,0x05;
001:>:wrote 32 bytes
001:>:received 32 bytes
001:>:09dc: Event XKEYBOARD-XkbEvent(85) type=2 time=0x018d8072 device=0x03 not-yet-supported=0x10,0x00,0x00,0x10,0x00,0x00,0x00,0x00,0x00,0x00,0x10,0x10,0x10,0x10,0x10,0x00,0x01,0x90,0x11,0x00,0x00,0x87,0x05;
001:>:wrote 32 bytes
001:>:received 32 bytes
001:>:09dc: Event XKEYBOARD-XkbEvent(85) type=2 time=0x018d8073 device=0x03 not-yet-supported=0x10,0x00,0x00,0x10,0x01,0x00,0x00,0x00,0x00,0x01,0x90,0x10,0x10,0x10,0x90,0x00,0x01,0x90,0x11,0x00,0x00,0x87,0x05;

其工作流程大致如下：

通过套接字地址族AF_INET判断是tcp通信还是本地domain socket通信，然后通过generateSocketName或者calculateTCPport拿到addr相关的信息
进入mainqueue死循环读取socket通信数据
通过parse_server(c)翻译Event事件通信，然后打印输出
parse_client(c)翻译Requst请求通信，然后打印输出

协议分析

xtrace通过拦截X11协议通信来进行分析。它捕获传输到X服务器的请求以及服务器对这些请求的响应，将他们解析化以日志输出的形式打印出来。所以本质来说协议分析指的是X11协议交互分析，需要对 X11相关的协议做到非常了解，即每个协议有什么功能，在xcb中是如何处理，在xserver中又是如何处理。受限于篇幅，笔者在此不会阐述所有的协议分析，而是拿我们平时常用的一些软件做一些分析和介绍。

日志流关键字	含义或用途
Present-Request(148,1)	客户端用于GLX等送显
Request(1): CreateWindow	请求创建X窗口，shm、glx都有
GLX-Request(152,3): glXCreateContext	请求创建GLX上下文，可以用来判断客户端是否GLX应用
MIT-SHM-Request(130,3): PutImage	X11 shm客户端请求更新图像
Event XKEYBOARD-XkbEvent(85)	xserver键盘事件传递给X客户端
Event Generic(35) XInputExtension	鼠标事件，后面带着ButtonPress、ButtonRelease、Motion等
Request(36): GrabServer	grab请求
Request(37): UngrabServer	解除grab请求
DeleteProperty	请求删除X11窗口的一些属性
ChangeProperty	改变X11窗口的一些属性
PropertyNotify	窗口属性改变发送事件通知客户端
MIT-SHM-Request(130,4): GetImage	shm方式获取屏幕图像
Request(62): CopyArea	复制屏幕一部分区域图像（离屏）
Request(53): CreatePixmap	创建图像（离屏）

上述表格中只是介绍了常见部分的协议，X协议非常的丰富，完整的模块如下所示：

XCB BigRequests API 发送和接受超过请求长度(65535字节)限制的数据
XCB Composite API 支持窗口合成，将多个窗口的内容合成最终的显示图像
XCB Damage API 用于跟踪窗口或者绘图上下文的可视区域的改变
XCB DPMS API 用于管理显示器的电源管理功能，控制显示器电源模式
XCB DRI2 API 支持直接渲染和硬件加速
XCB DRI3 API 支持直接渲染和硬件加速，对DRI2的扩展和改进
XCB Glx API 提供GLX接口创建OpenGL上下文，进行图形渲染和交互
XCB Present API 实现高性能的图像呈现在屏幕上
XCB RandR API 管理显示器的分辨率、屏幕方向和显示器布局等
XCB Record API 记录X服务器的事件流，以便进行调试、分析等
XCB Render API xrender绘图
XCB ScreenSaver API 管理屏幕保护程序的行为和状态
XCB Shape API 用于创建和操作不规则窗口的形状
XCB Shm API 应用程序能够通过共享内存的方式高效的传输图像
XCB Sync API 实现同步操作和时间戳的管理，确保预期的时序
XCB XCMisc API 提供额外的杂项函数和功能，获取一些服务器信息
XCB Core API 核心部分，提供了基本通信功能和操作
XCB Xevie API 拦截和处理X服务器上的事件流
XCB XF86Dri API 直接渲染，直接访问图形硬件，提高图形性能和效率
XCB XFixes API 增强功能：光标、窗口形状、窗口属性、窗口位置
XCB Xinerama API 用于管理多个显示器的配置和操作
XCB Input API 处理输入事件（如键盘、鼠标、触摸屏等）交互
XCB xkb API 配置与操作键盘相关的设置，键盘布局和状态
XCB XPrint API 直接从应用程序打印文档、图像和其他内容
XCB API xcb基础功能
XCB SELinux API 在应用程序中管理selinux安全策略和执行安全操作
XCB Test API 测试协议，常用于远程控制
XCB Xv API xvideo相关，用于视频渲染、视频加速、获取视频信息
XCB XvMC API 在GPU上执行视频解码和运动补偿功能笔者在工作中也有时对xtrace日志无法分析到有用信息,此时会查看XCB帮助文档，通过分析对比查找到相关的xcb函数，从而逐渐熟悉X11协议。

总结

总体来说xtrace是一个有用的工具，对于笔者来说经常会接触生态软件的图形显示问题，对于少部分软件开发商不愿意提供代码和问题复现最小demo，此时其软件对于笔者来说是一个黑盒，当问题边界靠近X相关的技术时，笔者会使用xtrace去详细分析该软件的详细功能，往往这可以在底层剖析软件的显示工作方式，配合系统上相关的组建库代码，可以方便地处理客户的紧急问题。笔者编写这篇文档是希望可以鼓励更多的同事使用xtrace，这个工具可以帮助你熟悉X11的工具原理，同时也可以理解像qt、gtk等UI库的底层实现，在定位系统复制粘贴、图形显示、拖拽、窗口相关的问题时可以提供更加底层的日志，方便更加精准地定位问题根因！

参考资料

X11
XServer

drm介绍

deepin 社区官方博客 — Wed, 01 Nov 2023 05:19:31 +0000

介绍

随着Linux图形发展的需求增长，需要更多的图形功能和性能，这促成了Direct Rending Infastructure（DRI）和Direct Rendering Manager（DRM）的出现，DRM是一个内核级别的子系统，提供了对图形设备的管理和访问控制，它允许用户空间的图形库和应用程序直接访问GPU进行渲染，而无需操作系统介入，它的主要作用如下：

图形硬件管理：DRM负责管理图形硬件资源，如显存、显卡以及显示设备。它允许内核与这些硬件设备进行通信和控制。
图形加速：提供对硬件加速功能的支持，例如3D渲染和视频加速。这使得图形渲染更加高效和流畅。
多显示器支持：允许多个显示器的管理和配置，包括扩展桌面、镜像模式等。
用户空间接口：提供了用户空间图形库（如Mesa 3D等）和应用程序与内核中DRM子系统进行通信的接口。
支持不同的图形协议：DRM在支持X Window System（X11）的同时，也能与新一代图形协议，如Wayland，进行整合。

这种更好的性能、3D加速和对硬件的更直接访问使得它可以支持X Window System和Wayland的图形输出和管理。其现状如下：

持续发展：随着硬件技术和图形需求的不断演进，DRM在Linux内核中也在不断发展。新的功能和改进不断加入，以满足新一代图形硬件和应用程序的需求。
多厂商支持：DRM的发展得到了多家硬件厂商的支持，这包括AMD、Intel、NVIDIA等，它们为Linux内核开发并贡献了各自硬件的DRM驱动程序。
支持新技术：DRM也在逐步支持新的图形技术，例如，对于低功耗图形处理的优化、支持更高分辨率、HDR显示以及机器学习和AI加速等方面的改进。
Wayland和DRM集成：Wayland作为新一代图形显示协议，与DRM更为紧密地整合，提供更为直接和高效的图形渲染和显示方式。

总体而言，现如今很多Linux发行版上图形服务器后端都是对接的drm实现图形输出和相关控制，DRM在Linux图形子系统中扮演着关键角色，随着技术和需求的不断发展，它持续进化以适应新的硬件和应用场景，为Linux系统提供了强大的图形渲染支持。

图1. DRM时间线

DRM剖析

Framebuffer && DRM

在谈drm之前必须先了解一下它的前辈Framebuffer，Framebuffer是指一块内存区域，用户存储显示设备上每个像素的颜色信息。在早期的计算机系统中，操作系统直接将图形数据写入这块显存区域，这被称为直接显存访问（Direct Framebuffer Access），这种方式简单、直接，但随着图形复杂程度增加和硬件发展，它变得难以满足高分辨率和复杂图形的需求，随着事件的推移，由DRM提供了更多先进的功能，它追加能替代了Framebuffer，并称为linux图形系统的主要组成部分（图形框架演变如下图2）。然而Frambuffer仍然在某些特定场景下有其用户之地，尤其是在一些嵌入式系统和特定的硬件上。总的来说，Framebuffer到DRM的发展代表了图形处理在Linux系统中的进步和演进，从最初的直接访问到高级的硬件加速和更加强大的图形功能。drm为显示硬件的适配和图形的发展贡献了很大的力量。

图2. Framebuffer到DRM

drm-plane

drm_plane本质是对显示控制器中scanout硬件的抽象。简单来说，给定一个plane，可以让其与一个framebuffer关联表示进行scanout的数据，同时控制scanout时进行的额外操作，比如colorspace的改变，旋转、拉伸、偏移等操作。drm_plane是与硬件强相关的，显示控制器支持的plane是固定的，其支持的功能也是由硬件决定的。所有的drm_plane必为三种类型之一：

Primary - 主plane，一般控制整个显示器的输出。CRTC必须要有一个这样的plane。
Curosr - 表示鼠标光标图层（可选），一般启用的话称其为开启硬件光标，代码如下，流程如下图3。
Overlay - 叠加plane，可以在主plane上叠加一层输出，可选。

....
if (cursor != NULL && drm_connector_is_cursor_visible(conn)) {
struct wlr_drm_fb *cursor_fb = get_next_cursor_fb(conn);
if (cursor_fb == NULL) {
wlr_drm_conn_log(conn, WLR_DEBUG, "Failed to acquire cursor FB");
return false;
}
drmModeFB *drm_fb = drmModeGetFB(drm->fd, cursor_fb->id);
if (drm_fb == NULL) {
wlr_drm_conn_log_errno(conn, WLR_DEBUG, "Failed to get cursor "
"BO handle: drmModeGetFB failed");
return false;
}
uint32_t cursor_handle = drm_fb->handle;
uint32_t cursor_width = drm_fb->width;
uint32_t cursor_height = drm_fb->height;
drmModeFreeFB(drm_fb);
// 设置硬件光标，更新光标图像buffer
 int ret = drmModeSetCursor(drm->fd, crtc->id, cursor_handle,
cursor_width, cursor_height);
int set_cursor_errno = errno;
if (drmCloseBufferHandle(drm->fd, cursor_handle) != 0) {
wlr_log_errno(WLR_ERROR, "drmCloseBufferHandle failed");
}
if (ret != 0) {
wlr_drm_conn_log(conn, WLR_DEBUG, "drmModeSetCursor failed: %s",
strerror(set_cursor_errno));
return false;
}
// 移动硬件光标位置
 if (drmModeMoveCursor(drm->fd,
crtc->id, conn->cursor_x, conn->cursor_y) != 0) {
wlr_drm_conn_log_errno(conn, WLR_ERROR, "drmModeMoveCursor failed");
return false;
}
} else {
if (drmModeSetCursor(drm->fd, crtc->id, 0, 0, 0)) {
wlr_drm_conn_log_errno(conn, WLR_DEBUG, "drmModeSetCursor failed");
return false;
}
}
....

图3. drm-plane框架图

图4. 多drm-plane合成流程图

在笔者看来，drm-plane与layer的概念类似，只是更加偏向硬件底层概念，开发者可以通过控制显示相关的参数将plane投显到显示器上任何区域（参考图5），这种映射机制提供了非常方便地偏移、缩放方法，如果在这一层上实现移动和缩放等动画，效率将会比使用OpenGL等API制作高，将频繁变化的图像抽象工作在一个单独的drm-plane也可以达到提高性能和省电的目的。

名字	描述
SRC_X	当前framebuffer crop区域的起始偏移x坐标
SRC_Y	当前framebuffer crop区域的起始偏移y坐标
SRC_W	当前framebuffer crop区域的宽度
SRC_H	当前framebuffer crop区域的高度
CRTC_X	屏幕显示区域的起始偏移x坐标
CRTC_Y	屏幕显示区域的起始偏移y坐标
CRTC_W	屏幕显示区域的宽度
CRTC_H	屏幕显示区域的高度

表1. drm-plane部分属性表

图5. drm-plane送显参数控制

crtc（Cathode Ray Tube Controller）

CRTC 是显示控制器中的一个重要部分，主要用于管理显示设备的扫描和刷新。CRTC 负责生成视频信号的定时和同步，控制屏幕上像素的扫描和刷新，以确保正确的图像显示。它管理像素的输出到屏幕上的确切位置，以及刷新率、分辨率等显示参数。在现代的图形处理中，CRTC通常由图形处理单元（GPU）或显示控制器中的专用部分来控制，以确保正确的图像输出。

图6. crtc框架图

drm legacy链路通过调用drmModePageFlip请求crtc更新显示器图像，其代码如下，流程如图6所示：

static bool legacy_crtc_commit(struct wlr_drm_connector *conn,
const struct wlr_drm_connector_state *state,
uint32_t flags, bool test_only) {
....
if (flags & DRM_MODE_PAGE_FLIP_EVENT) {
uint32_t page_flags = DRM_MODE_PAGE_FLIP_EVENT;
if (flags & DRM_MODE_PAGE_FLIP_ASYNC) {
page_flags |= DRM_MODE_PAGE_FLIP_ASYNC;
}
if (drmModePageFlip(drm->fd, crtc->id, fb_id,
page_flags, drm)) {
wlr_drm_conn_log_errno(conn, WLR_ERROR, "drmModePageFlip failed");
return false;
}
}
return true;
}

图7. buffer更新流程图

encoder

编码器从CRTC获取像素数据，并将其转换为适合任何连接器的格式。在某些设备上，CRTC可以将数据发送到多个编码器。在这种情况下，两个编码器将从同一扫描输出缓冲区接收数据，从而在连接到每个编码器的连接器上产生“克隆”显示配置。在Linux系统中，DRM（Direct Rendering Manager）是用于处理图形显示的子系统，负责在用户空间和图形硬件之间提供接口。DRM编码器在Linux中扮演了关键角色，主要用于对图形和视频内容进行编码、解码、处理和显示。在DRM框架中，编码器的作用包括但不限于：

视频压缩和解压缩：编码器负责对视频内容进行压缩，以减小数据量并更有效地传输和存储视频流。解码器用于解压缩视频内容，以便图形硬件能够正确地渲染和显示内容。
图形处理和渲染： DRM编码器能够处理图形和视频流，进行渲染和合成，然后将图像数据发送到显示设备以在屏幕上显示。
硬件加速： DRM编码器还可以利用硬件加速功能，以便更快地处理图形和视频内容。这有助于提高性能和效率，特别是对于高分辨率视频或图形内容的处理。
支持多种编解码标准： DRM编码器能够支持多种视频编解码标准，如H.264、H.265等，确保对不同格式的视频流进行正确的处理。在Linux系统中，DRM编码器与图形驱动程序、图形处理单元（GPU）和显示设备等硬件密切相关。它允许Linux系统管理和控制图形硬件，处理视频流并在屏幕上显示图像，同时也与DRM系统中的访问控制和安全性机制集成，确保受保护内容的安全传输和显示。

图8. encoder框架图

connector

DRM connectors是用于管理和描述图形设备的连接器或端口。它们提供了对显示设备的连接和属性描述。在图形系统中，这些连接器可以代表诸如HDMI、DisplayPort、DVI等物理连接接口，而它们也可以描述内部连接，例如LCD panels。DRM connectors 在 Linux 中的作用包括：

显示设备连接描述： DRM connectors 提供了关于显示设备的物理连接信息，比如类型（HDMI、VGA、DisplayPort等）、连接状态以及支持的分辨率和刷新率等信息。
动态连接管理：它们可以监测连接和断开事件。当显示设备插入或拔出时，DRM connectors 可以检测到这些变化，并通知系统相应的变化。这使系统能够动态调整图形配置以适应新的连接或断开状态。
多显示器支持： DRM connectors 允许系统管理多个显示器的连接和配置。这使得可以同时使用多个显示器或监视器，或者在不同的显示设备上显示不同的内容。
显示属性查询和配置：通过 DRM connectors，可以查询连接器支持的分辨率、刷新率以及其他显示属性。这使系统可以调整和配置图形设备，以最佳方式显示图形内容。

总体来说，DRM connectors 在 Linux 中的作用是管理显示设备的物理连接、状态和属性，使系统能够动态适应不同的显示设备、支持多个显示器，并提供相应的配置信息，以便正确地显示图形内容。

图9. connector框架图

framebuffer

framebuffer是一个重要概念。Framebuffers是用于存储屏幕上每个像素的颜色和其他相关信息的内存区域。在DRM中，framebuffer提供了一个抽象接口，允许用户空间程序访问和操作显存，以便渲染图形数据。其作用包括：

图形数据存储： Framebuffers提供一个区域，用于存储图形数据，包括每个像素的颜色、透明度等信息。这些数据构成了屏幕上显示的图像。
直接访问屏幕数据：通过framebuffers，用户空间程序或操作系统内核能够直接访问和操作图形数据，而无需经过额外的复杂处理。
硬件抽象层： Framebuffers提供了一个硬件无关的抽象接口，这意味着不同的图形设备和硬件都可以通过相同的接口进行访问和操作。
显示图像： Framebuffers存储了最终用于在屏幕上显示的图像数据。图形数据在 framebuffer中进行组织和处理，然后通过显示控制器输出到屏幕。

在DRM 中，framebuffers通常与CRTC和显示控制器等组件一起工作。framebuffers提供的抽象层允许操作系统或应用程序以统一的方式对图形数据进行处理和管理，无论具体的硬件设备是什么样的。总之，framebuffers 在 Linux 的 DRM 中提供了一个接口和数据结构，用于存储、操作和管理图形数据，使其能够在屏幕上正确地显示图像。

图10. framebuffer内存结构图

drm调试工具

drm_info

用于转储有关 DRM 设备信息的小实用程序

drm_info
Node: /dev/dri/card1
├───Driver: i915 (Intel Graphics) version 1.6.0 (20201103)
│ ├───DRM_CLIENT_CAP_STEREO_3D supported
│ ├───DRM_CLIENT_CAP_UNIVERSAL_PLANES supported
│ ├───DRM_CLIENT_CAP_ATOMIC supported
│ ├───DRM_CLIENT_CAP_ASPECT_RATIO supported
│ ├───DRM_CLIENT_CAP_WRITEBACK_CONNECTORS supported
│ ├───DRM_CAP_DUMB_BUFFER = 1
│ ├───DRM_CAP_VBLANK_HIGH_CRTC = 1
│ ├───DRM_CAP_DUMB_PREFERRED_DEPTH = 24
│ ├───DRM_CAP_DUMB_PREFER_SHADOW = 1
│ ├───DRM_CAP_PRIME = 3
│ ├───DRM_CAP_TIMESTAMP_MONOTONIC = 1
│ ├───DRM_CAP_ASYNC_PAGE_FLIP = 1
│ ├───DRM_CAP_CURSOR_WIDTH = 256
│ ├───DRM_CAP_CURSOR_HEIGHT = 256
│ ├───DRM_CAP_ADDFB2_MODIFIERS = 1
│ ├───DRM_CAP_PAGE_FLIP_TARGET = 0
│ ├───DRM_CAP_CRTC_IN_VBLANK_EVENT = 1
│ ├───DRM_CAP_SYNCOBJ = 1
│ └───DRM_CAP_SYNCOBJ_TIMELINE = 1
├───Device: PCI 8086:46aa Intel Corporation Alder Lake-UP4 GT2 [Iris Xe Graphics]
│ └───Available nodes: primary, render
├───Framebuffer size
│ ├───Width: [0, 16384]
│ └───Height: [0, 16384]
├───Connectors
│ ├───Connector 0
│ │ ├───Object ID: 236
│ │ ├───Type: eDP
│ │ ├───Status: connected
│ │ ├───Physical size: 290x180 mm
│ │ ├───Subpixel: unknown
│ │ ├───Encoders: {0}
│ │ ├───Modes
│ │ │ └───2880x1800@60.00 preferred driver phsync nvsync
│ │ └───Properties
│ │ ├───"EDID" (immutable): blob = 266
│ │ ├───"DPMS": enum {On, Standby, Suspend, Off} = On
│ │ ├───"link-status": enum {Good, Bad} = Good
│ │ ├───"non-desktop" (immutable): range [0, 1] = 0
│ │ ├───"TILE" (immutable): blob = 0
│ │ ├───"CRTC_ID" (atomic): object CRTC = 80
│ │ ├───"scaling mode": enum {Full, Center, Full aspect} = Full aspect
│ │ ├───"panel orientation" (immutable): enum {Normal, Upside Down, Left Side Up, Right Side Up} = Normal
│ │ ├───"Broadcast RGB": enum {Automatic, Full, Limited 16:235} = Automatic
│ │ ├───"max bpc": range [6, 12] = 10
│ │ ├───"Colorspace": enum {Default, BT709_YCC, XVYCC_601, XVYCC_709, SYCC_601, opYCC_601, opRGB, BT2020_CYCC, BT2020_RGB, BT2020_YCC, DCI-P3_RGB_D65, RGB_WIDE_FIXED, RGB_WIDE_FLOAT, BT601_YCC} = Default
│ │ ├───"HDR_OUTPUT_METADATA": blob = 0
│ │ └───"vrr_capable" (immutable): range [0, 1] = 0
│ ├───Connector 1
│ │ ├───Object ID: 245
│ │ ├───Type: DisplayPort
│ │ ├───Status: disconnected
│ │ ├───Encoders: {1}
│ │ └───Properties
│ │ ├───"EDID" (immutable): blob = 0
│ │ ├───"DPMS": enum {On, Standby, Suspend, Off} = Off
│ │ ├───"link-status": enum {Good, Bad} = Good
│ │ ├───"non-desktop" (immutable): range [0, 1] = 0
│ │ ├───"TILE" (immutable): blob = 0
│ │ ├───"CRTC_ID" (atomic): object CRTC = 0
│ │ ├───"subconnector" (immutable): enum {Unknown, VGA, DVI-D, HDMI, DP, Wireless, Native} = Unknown
│ │ ├───"audio": enum {force-dvi, off, auto, on} = auto
│ │ ├───"Broadcast RGB": enum {Automatic, Full, Limited 16:235} = Automatic
│ │ ├───"max bpc": range [6, 12] = 12
│ │ ├───"Colorspace": enum {Default, BT709_YCC, XVYCC_601, XVYCC_709, SYCC_601, opYCC_601, opRGB, BT2020_CYCC, BT2020_RGB, BT2020_YCC, DCI-P3_RGB_D65, RGB_WIDE_FIXED, RGB_WIDE_FLOAT, BT601_YCC} = Default
│ │ ├───"HDR_OUTPUT_METADATA": blob = 0
│ │ ├───"vrr_capable" (immutable): range [0, 1] = 0
│ │ ├───"Content Protection": enum {Undesired, Desired, Enabled} = Undesired
│ │ └───"HDCP Content Type": enum {HDCP Type0, HDCP Type1} = HDCP Type0
│ └───Connector 2
│ ├───Object ID: 258
│ ├───Type: DisplayPort
│ ├───Status: disconnected
│ ├───Encoders: {6}
│ └───Properties
│ ├───"EDID" (immutable): blob = 0
│ ├───"DPMS": enum {On, Standby, Suspend, Off} = Off
│ ├───"link-status": enum {Good, Bad} = Good
│ ├───"non-desktop" (immutable): range [0, 1] = 0
│ ├───"TILE" (immutable): blob = 0
│ ├───"CRTC_ID" (atomic): object CRTC = 0
│ ├───"subconnector" (immutable): enum {Unknown, VGA, DVI-D, HDMI, DP, Wireless, Native} = Unknown
│ ├───"audio": enum {force-dvi, off, auto, on} = auto
│ ├───"Broadcast RGB": enum {Automatic, Full, Limited 16:235} = Automatic
│ ├───"max bpc": range [6, 12] = 12
│ ├───"Colorspace": enum {Default, BT709_YCC, XVYCC_601, XVYCC_709, SYCC_601, opYCC_601, opRGB, BT2020_CYCC, BT2020_RGB, BT2020_YCC, DCI-P3_RGB_D65, RGB_WIDE_FIXED, RGB_WIDE_FLOAT, BT601_YCC} = Default
│ ├───"HDR_OUTPUT_METADATA": blob = 0
│ ├───"vrr_capable" (immutable): range [0, 1] = 0
│ ├───"Content Protection": enum {Undesired, Desired, Enabled} = Undesired
│ └───"HDCP Content Type": enum {HDCP Type0, HDCP Type1} = HDCP Type0
├───Encoders
│ ├───Encoder 0
│ │ ├───Object ID: 235
│ │ ├───Type: TMDS
│ │ ├───CRTCS: {0, 1, 2, 3}
│ │ └───Clones: {0}
│ ├───Encoder 1
│ │ ├───Object ID: 244
│ │ ├───Type: TMDS
│ │ ├───CRTCS: {0, 1, 2, 3}
│ │ └───Clones: {1}
.........
├───CRTCs
│ ├───CRTC 0
│ │ ├───Object ID: 80
│ │ ├───Legacy info
│ │ │ ├───Mode: 2880x1800@60.00 preferred driver phsync nvsync
│ │ │ └───Gamma size: 256
│ │ └───Properties
│ │ ├───"ACTIVE" (atomic): range [0, 1] = 1
│ │ ├───"MODE_ID" (atomic): blob = 271
│ │ │ └───2880x1800@60.00 preferred driver phsync nvsync
│ │ ├───"OUT_FENCE_PTR" (atomic): range [0, UINT64_MAX] = 0
│ │ ├───"VRR_ENABLED": range [0, 1] = 0
│ │ ├───"SCALING_FILTER": enum {Default, Nearest Neighbor} = Default
│ │ ├───"DEGAMMA_LUT": blob = 0
│ │ ├───"DEGAMMA_LUT_SIZE" (immutable): range [0, UINT32_MAX] = 129
│ │ ├───"CTM": blob = 0
│ │ ├───"GAMMA_LUT": blob = 270
│ │ └───"GAMMA_LUT_SIZE" (immutable): range [0, UINT32_MAX] = 1024
........
└───Planes
├───Plane 0
│ ├───Object ID: 31
│ ├───CRTCs: {0}
│ ├───Legacy info
│ │ ├───FB ID: 237
│ │ │ ├───Object ID: 237
│ │ │ ├───Size: 2880x1800
│ │ │ ├───Format: ARGB2101010 (0x30335241)
│ │ │ ├───Modifier: I915_FORMAT_MOD_Y_TILED (0x100000000000002)
│ │ │ └───Planes:
│ │ │ └───Plane 0: offset = 0, pitch = 11520 bytes
│ │ └───Formats:
│ │ ├───C8 (0x20203843)
│ │ ├───RGB565 (0x36314752)
│ │ ├───XRGB8888 (0x34325258)
│ │ ├───XBGR8888 (0x34324258)
│ │ ├───ARGB8888 (0x34325241)
│ │ ├───ABGR8888 (0x34324241)
.....

drm_monitor

用于监控 KMS 状态的 CLI 工具

drm_monitor -d /dev/dri/card1
CRTC 80: seq=30095325875 ns=3076787603594 delta_ns=16668012 Hz=59.995157
CRTC 131: seq=0 ns=0 delta_ns=0 Hz=0.000000
CRTC 182: seq=0 ns=0 delta_ns=0 Hz=0.000000
CRTC 233: seq=0 ns=0 delta_ns=0 Hz=0.000000

参考资料

浅析 linux 电源配置

deepin 社区官方博客 — Tue, 31 Oct 2023 13:00:00 +0000

一、背景

近期，我们收到用户反馈，在使用 deepin 系统过程中遇到了 CPU 功耗过高导致的设备发热、续航较差情况，而用户在这些负载场景下，CPU 的占用往往不高。为了解决这个痛点，统信软件开源社区中心特别成立专项计划，对于 deepin 的电源进行专项优化，本文旨在针对此问题根因进行分析于说明。

在对电源进行专项优化之前，我们首先对 deepin 系统进行了深入的调查和分析，以了解其在负载场景下的实际运行情况。经过对 CPU 使用率和功耗的监测，我们发现了一个令人惊讶的事实：尽管在高负载场景下 CPU 的占用率不高，但其功耗却持续升高，最终导致设备发热并影响续航。也就是说，我们前期做的省电优化工作，不仅无效，还起了反作用（具体情况作者将在下文作出仔细说明）。

二、问题

1. 内核

最开始发现问题的地方在内核。有用户将我们的内核和 ubuntu 的内核进行对比后发现，虽然我们的系统和 ubuntu 系统的性能差不多，但是在发热和续航上，我们较 ubuntu 落后较多。有用户在 deepin 系统上使用 ubuntu 和其他开源 linux 发行版的配置文件分别编译内核，发现 deepin 的主要问题存在于发热控制之上。我们的测试同事高度重视这一社区反馈，遂对社区用户反馈的问题进行复现，佐证了这一现象。

对于这种问题，我们立即联系了内核研发部的同事，并邀请部分对内核配置有一定研究的社区用户共同参与。在大家的合力排查下，我们发现，deepin v23 中提供的 HWE 内核存在部分 debug 和无用的内核选项被开启的情况，并且部分节电功能实际未能获得启用，这些都在一定程度上导致了 deepin v23 的续航表现不佳。

2. 系统

在系统层面，我重新审视了 dde-daemon 提供的电源调度模块，并且对比内核文档提供的文件接口，分析我们用户使用的电源模式，发现其中存在可以优化的空间。这将是本文着重讲解的内容之一。

三、前置知识

1.ACPI

ACPI 是 Advanced Configuration and Power Interface 的缩写，是一种计算机硬件和操作系统之间交换能源相关信息的接口规范。它定义了计算机硬件的能源相关信息，如电源供应器状态、设备功耗、设备功率因数等。ACPI 是操作系统控制计算机硬件能源管理的标准，同时也是硬件厂商和操作系统之间通信的标准。

在 deepin 系统中，ACPI 负责处理计算机硬件的能源管理，它与 deepin 系统的电源管理模块进行交互，以实现对计算机硬件的能源管理。

在分析系统层面的问题时，我们需要了解 ACPI 和电源管理模块的作用和功能，以及它们是如何协同工作的。在本文中，我们将会详细讲解 ACPI 的工作原理以及 deepin 系统中的电源调度模块工作模式，并提出可行优化建议。

首先，让我们了解一下 ACPI 的工作原理。当计算机硬件发生电源变化时，ACPI 会收集硬件信息，并向操作系统发送电源请求。操作系统收到电源请求后，会根据用户配置自动调整各个硬件的电源策略。而 deepin 系统的电源模块则是帮助用户生成配置来调整 ACPI 的行为。所以在这一方面，我们能做的就是向 ACPI 提供合理的电源策略，在保证性能的同时，降低设备温度并提升续航表现。

2.平台电源配置

相关内核文档<https://docs.kernel.org/userspace-api/sysfs-platform_profile.html>
UEFI ACPI 文档<https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/index.html> 平台电源配置是电源管理模块的一个重要组成部分，它用于管理计算机平台硬件（指所有支持 ACPI 的设备）的电源状态，而 CPU 也是属于 ACPI 设备的一部分。不过 CPU 是计算机的核心发热大户，对于其使用平台电源管理可能粒度较粗，所以 APCI 引入了一些 CPU 独有的性能管理方式，在下一小节将详细说明。

平台电源配置提供了三种可选模式：performance（性能模式），balance（平衡模式），low-power（节能模式）。一般情况下，用户使用平衡模式就可以。在台式机和 mini 主机类（对于功耗和发热没有任何要求）设备上默认提供性能模式，在笔记本等移动设备上默认提供平衡模式。默认不提供节能模式，因为某些 ACPI 设备在节能模式工作过程中可能出现“睡死现象”，所以为了避免此问题，默认不提供 low-power 节电模式。

3.CPU 电源配置

传统电源模式（SCalling）内核文档<https://www.kernel.org/doc/html/v6.1/admin-guide/pm/cpufreq.html>
Intel PState 内核文档<https://www.kernel.org/doc/html/v6.1/admin-guide/pm/intel_pstate.html>
AMD PState 内核文档<https://docs.kernel.org/admin-guide/pm/amd-pstate.html> 如果有时间，可以自行研读上述电源文档，就很容易理解 CPU 电源配置相关内容。作者在这里的讲述将忽略大量技术细节和实现方式，仅表述如何调整 CPU 的电源模式

在/sys/devices/system/cpu/cpufreq目录下有许多文件名为policy<x>（x 代表核心编号），这些文件对应着你电脑上的 CPU 核心，而 CPU 的电源调度细节就在这些文件夹里面。在policy<x>目录下有一个文件`scaling_driver``,使用 cat 或其他方式访问它，得到的结果就是我们当前使用的调度器：

intel_cpufreq / acpi_cpufreq : 使用 scaling freq 调度
intel_pastate : 使用 Intel Pstate 调度
amd-pstate : 使用 AMD Pstate 调度

scalling freq 调度

这是最传统的 CPU 调度方式，你可以在 policy文件夹下的 scaling_available_governors 获取可选电源模式：

英文	中文	含义
performance	性能模式	最极致的性能表现，最火热的 CPU 温度，最短的续航。
powersave	节能模式	为绿色地球出一份力。
balance	平衡模式	性能和续航兼顾。小孩子才做选择，我全都要。
schedutil	平衡模式	平衡模式的一种，使用不同算法进行调度。
ondemand	平衡模式	平衡模式的一种，根据当前 CPU 负载动态调整频率。当负载大于阈值时调整到最高频率，其他情况按负载比例计算频率。
conservative	平衡模式	平衡模式的一种，根据当前 CPU 负载动态调整频率。当负载大于最大阈值时步进递增频率，当负载小于最低阈值时步进递减。
userspace	用户模式	以用户指定的频率运行 CPU，可通过/sys/devices/system/cpu/cpuX/cpufreq/scaling_setspeed 进行配置

你可能好奇，为啥这里有这么多平衡模式，其实这些平衡模式的作用都是是一样的：平衡性能和续航，不过使用的算法可能不同，这里我不做详细说明，我在网络上找到一些详细资料可以参考，有兴趣的朋友可自行查阅：

oppo 内核团队：schedutil governor 情景分析：http://www.wowotech.net/process_management/schedutil_governor.html
linux 内核文档：schedutil governor：https://www.kernel.org/doc/html/next/translations/zh_CN/scheduler/schedutil.html
Arch wiki：https://wiki.archlinux.org/title/CPU_frequency_scaling 我们可以更改 scaling_governors 来更改此核心的电源调度（注意：只能更改为 scaling_available_governors 文件中列出的电源调度，不同电脑可能存在差异）。

Intel Pstate

这是 Intel 近几代 CPU 独享的 moment，内核开启 intel pstate 后（V23 内核默认开启）你会发现在 policy文件夹下多了几个文件：

我们只需要关注：

energy_performance_available_perference : 可用的 pstate 电源调度
energy_performance_perference：当前选定的 pstate 电源调度，可以更改此文件内容来更改电源调度
在 Intel Pstate 中出现了两个新的调度方案：
balance_performance : 平衡偏性能，平时工作频率不高，在负载增大时能快速响应
balance_power : 平衡偏节能，电源策略较为保守在部分电脑上还有 default 方案，此方案就是经过 pstate 优化过的 balance 策略。具体 PState 使用的黑魔法以及主动模式和被动模式的调度策略，可以参照内核文档进行分析。

AMD PState

这是 AMD ZEN2 以上用户，以及支持 kernel 6.4.x 用户独享的 moment。其实 AMD 在 6.1 内核已经做了 PState 的支持，不过是被动模式。

（Actvie Mode）主动模式

Active Mode 仅在内核版本大于 6.4 以上，且内核选项打开 AMD PState 时可用。可能需要在 grub 内加入启动参数以打开此功能：amd_pstate=active，也可以修改文件实现 Active Mode 的电源策略和 Intel PStatewi 类似。
（Passive Mode）被动模式

Passtive Mode 仅在内核大于 6.1 以上，且内核选项打开 AMD PState 时可用。可能需要在 grub 加入启动参数开启此功能：amd_pstate=passive，也可修改文件实现。

Passive Mode 提供两种电源模式，在/sys/device/system/cpu/cpufreq/scaling_governor文件进行调整：
- performance 使用 platform_profile 进行配置，调度积极性较高
- scheutils 在/sys/device/system/cpu/cpufreq/schedutil/rate_limit_us文件中调整调度粒度（两次调度的间隔时间）和 ACPI 的 scheutils 类/sys/device/system/cpu/cpufreq/scaling_governor
（Guided Mode）引导模式

Guided Mode 仅在内核大于 6.1 以上，且内核选项打开 AMD PState 时可用。可能需要在 grub 加入启动参数开启此功能：amd_pstate=guided，也可修改文件实现。这就类似汽车的自动挡，驱动程序请求最低和最大性能级别，平台自动选择此范围内适合当前工作负荷的性能级别。

4.GPU 电源管理部分

AMD GPU

如果是 AMD GPU 则需要更改两个文件（使用 tee 命令进行写入）：

/sys/class/drm/card0/device/power_dpm_state（这是一个遗留接口，目的是向后兼容）
performance 高性能模式
balance 平衡模式
battery 节能模式
/sys/class/drm/card0/device/power_dpm_force_performance_level

以下设置来自 AMD 官方驱动文档：

https://dri.freedesktop.org/docs/drm/gpu/amdgpu.html#power-dpm-force-performance-level

drm/amdgpu AMDgpu driver — The Linux Kernel documentation

power_dpm_force_performance_level:

AMD GPU 驱动程序提供了一个 sysfs API，用于调整某些与功率相关的参数。文件 power-dpm-force-performance-level 将用于执行此操作。它接受以下参数：

auto：当选择 auto 时，设备将尝试针对驱动中的当前条件动态选择最佳功率曲线
low：当选择低时，GPU 被强制到最低功率状态
high：当选择高时，GPU 被强制到最高功率状态
manual：当选择手动时，用户可以通过 sysfs pp_dpm_mclk、pp_dpm_sclk 和 pp_dpm_pcie 文件手动调整每个时钟域启用的电源状态，并通过 pp_power_profile_mode sysfs 文件调整电源状态转换方式。
profile_standard 固定时钟级别分析模式。此模式将时钟设置为固定级别，该级别因 ASIC 而异。这对于分析特定工作负载很有用（不常用）。
profile_min_sclk 最小 sclk 分析模式。此模式将 sclk 强制设置为最低级别。这对于分析最小功耗的场景很有用（不常用）。
profile_min_mclk 最小 mclk 分析模式。此模式将 mclk 强制设置为最低级别。这对于分析最小功耗的场景很有用（不常用）。
profile_peak 峰值分析模式。此模式将所有时钟（mclk、sclk、pcie）设置为最高级别。这对于分析最大性能的场景很有用（不常用）。

测试：

LOW 模式的跑分

auto 模式的跑分

high 模式的跑分

Intel GPU

intel GPU 使用的 i915 驱动，并不希望你对其做出调整，因为其驱动自带的电源策略已经足够聪明。不过你也可以通过 intel 提供的 intel-gpu-tools 进行调整和获取信息。

sudo apt install intel-gpu-tools

然后使用

sudo intel_gpu_frequency

来获取当前频率（当前使用的是 Intel A750）

可以看到 intel 的显卡驱动是在 600 MHz 到 2400 MHz 之间动态调整（如上图）

测试笔记本下 intel 核显跑分如下

Nvidia

由于 nvidia 驱动不开源，所以在系统层面无法对其做控制。

四、应用

应用级别的省电，应该就是在保证用户使用流畅度的情前提下下节省性能。之前也有用户提出过，是否能参照 vivo 的 origin3 os 的不公平调度算法来实现优化。毕竟安卓系统的底层也是 linux，理论上实现难度不大。

Cgroups，全称 Control Groups，是 Linux 内核提供的一种资源管理机制，用于对进程分组并对其资源进行限制和隔离。Cgroups 可以用于限制进程的 CPU、内存、磁盘、网络等资源，也可以用于限制进程的优先级和 IO 权限。利用其提供的能力，我们很容易实现类似不公平调度算法（我们新的 AM 天然支持 Cgroups 的操作），但是我还有一些顾虑：

不同于手机操作系统，计算机操作系统是多任务并行的，在多数窗口管理器下，我们并没有一个明显的前台应用，此时使用不公平调度可能存在隐患；
容易引发人机对抗。在我的观念里面，计算机是为人服务的，那么用户的意志必定是第一优先级，所以我们不应改变用户的行为，如果使用不平衡调度和用户预期不一致，会极大降低用户体验；
使用前后台区分应用，可能导致开销和收益比下降，性价比不高。linux 桌面不像安卓设备有明显前后台，那么用户频繁切换应用的操作将导致我们的调度器频繁切换调度，使得开销过大。我认为最佳的解决方案是：提供能力，但不提供方案。我们可以提供基于 Cgroups 方式修改应用组的优先级，然后让用户自己选择什么应用优先级更高，什么应用优先级低，以实现调度（比如在 dock 上右键选择优先级）或提供一套配置以供用户自由选择。

如果一个电脑需要使用不平衡调度来保证使用流畅性，可能这并不是一个操作系统能解决的问题，而更应该考虑硬件是否需要更换，以保证多任务使用的流畅性。

附录——常用的调试测试工具

1. S-tui

可以看到 CPU 频率变化，配合 stress 可以对 cpu 进行压力测试。

2. intel-gpu-tools

可以使用 intel_gpu_frequency 来获取和调整 i965 的驱动频率。

3. glmark2

GPU 跑分软件。

4. stress-ng

CPU 压力测试软件。

5. powertop

电源测试软件，可以看到电源的功耗和使用情况。

Wireshark构建编译随笔

deepin 社区官方博客 — Sun, 24 Sep 2023 17:14:57 +0000

随笔

在给Wireshark做完编译、调整、上架之后，我打算到论坛里看看大家对开源应用有没有什么疑惑的地方，没想到大家现在对开源的关注度这么高了。在看到最近一些闹得比较沸沸扬扬的话题之后，我也对我现在开源应用适配工作的很多地方产生了疑惑，我这样跟开源还有关系吗？

重新适配开源应用的意义

在一些实际的场景中，其实有很多"重复造轮子"的情况，即明确存在其他开源项目可用来替代的情况下仍然自己重头造一个项目来实现相同/类似的功能。比如各大桌面环境都有自己的一套文管:DDE的dde-file-manager、KDE的Dolphin，但严格意义上他们不是重复造轮子，而是更好地融入桌面环境中。另外一种情况就是我现在做的适配开源应用，我的作品很大一部分可以在系统的应用商店中找到。但细心的小伙伴可能会发现:

“诶，这个应用不是系统仓库里有吗？为什么还要消耗资源去重复适配?”
“Debian 12的这个应用已经去到3.6.1了，为什么商店里的还是3.6.0?”
“为什么软件官方已经提供了deepin可以直接安装的包，应用商店还要另起一个新包名互不兼容?”

想到这几个问题，大家是不是血压都上来了?这不就是妥妥重复劳动吗?别急，听我慢慢道出里面的小细节。我愿总结为两个核要义:平易、近人。

易用性

首先问大家一个问题，抛开命令真爱粉不谈，你认为用apt安装包方便还是在应用商店看着截图、应用描述、评论等等来一站式点击"安装"方便? 虽然命令也可以直接安装各种系统仓内的各种包，但对于新手用户个人认为还是有一定难度的。而且不使用应用商店来下载，很有可能就与应用商店各种特性擦肩而过了，比如定期的应用推荐、应用版本迭代的changelog。

用户侧体验优化

不知道大家有没有体验最近Wireshark-4.0.8，有使用过的朋友应该会发现我们很贴心的准备了两个desktop启动方式，一个是普通模式一个是root模式，中间的取舍故事今天就不多赘述了，大家有兴趣可以后面单独拎出来。至于为什么会设置这么两个模式?其实我在适配开源项目前一般都会预览大家在应用商店里的反馈，这次的举动主要是由于Wireshark用普通user权限可以打开程序，但只是能看个壳子，只有root权限打开才是完整的功能。而且大家也反馈了比较多这个情况，我在评估一段之间、测试可行性之后给大家带来了"两个desktop+提示窗+双语支持"的独家体验。 “两个desktop+提示窗"是为了让大家方便以不同的模式打开，“提示窗"则是根据不同模式给大家展示相关提示信息，“双语支持"则是根据系统语言来设置中文和其他语言下分别显示中文提示和英文提示，一定程度上兼顾海外友人的体验。

我观察了下，Wireshark编译之后的原版desktop文件是不提供这种级别的优化的；而现在deepin应用商店里的版本实实在在可以做到了这个层次的优化，亲近人心。大家可以把细节打在评论上。

生态多样性

严格意义上，每个包只有包名是相对唯一的，这也是因为大部分包管理器都会通过包名来检查该包的情况。但对于同一个应用特别是开源项目而言，它允许被多次修改分发，除了用版本号用以区分，也并没有强制要求每个人维护的包名都遵循同一个。但为什么Debian等主流发行版一般包名都会随着版本迭代而保留使用，一般并不轻易修改包名?个人认为有以下几个可能:

一般主流发行版仓库中某个重要项目/库为了保证长期稳定性和可维护性，一般都由同一个维护者负责维护，所以包名不会发生明显改动。
包名变动过大，相关联的其他包/库均需要重新调整依赖关系，不太利于用户体验和仓库维护管理。
接第一个情况，即便每个人都有编译开源项目的自由，但大家都比较自觉不会向系统仓中投递已经确切存在的包。

除此之外，如果你同时在应用商店和外部安装一个包名一致的应用，则只会保留版本较新的一个。或者说，如果你想要保留本地安装的版本，但你在应用商店里对其进行升级，那此时你本地的包就会被替换掉了。

稳定性测试

其实在开源应用上架到应用商店前都会有测试流程，大家也很难保障哪一个版本会有致命问题，或者哪一个版本会丧失预期特性。所以我们在选包之后，一般是先编译一遍，没有致命问题我们才进行其他操作，尽最大努力保驾护航。

适配开源应用的难度

要是你觉得我们就是单纯把一些官方提供的二进制归档文件甚至是直接可用的deb包转化来上架应用商店，比如Visual Studio Code。那我很坦白告诉你，就是单纯几个字，“解包–运行–重新打包”。但如果你是看了上文内容的话，就知道事情并不简单了。不只是从源码开始编译，核心在于如何与终端用户、各大开发者站在统一战线。当然，这里指的并不只是不断去满足用户的需要，这种可能会比较适合C端方向。我更希望的，是帮助用户在专业性比较强的问题面前能够提供满意的答卷，比如这次Wireshark，其实大部分用户真的不一定知道需要使用root来运行，所以我们做了优化。应用/软件包只是一个普通产出物，不可替代的其实是整个适配过程中与其他人产生差异化的用户思维。

结语

曾经，我觉得我适配出来的开源应用只上架应用商店确实是玷污了开源，而且我并不是对程序Core本身做出了代码性贡献，这些优化充其量可能也就是普通建议而已。但后来，能看到大家对开源的支持，我也释怀了。我希望以后有机会可以分享我在编译中发生的故事，同时也很支持使用其他发行版的小伙伴可以使用我在deepin上编译、优化调整之后的开源应用。我也希望在开源这片蓝天里，我不是孤军奋战。

deepin-IDE中的调试技术

deepin 社区官方博客 — Fri, 22 Sep 2023 10:19:31 +0000

前不久深度科技旗下deepin社区发布了自己的 IDE：deepin-IDE，得到了全网用户尤其是开源社区用户的广泛关注，目前在 GitHub（https://github.com/linuxdeepin/deepin-unioncode）仓库的 star 数量已经达到 600 多个，说明大家的热情还是很高涨的。

为了从技术层面给大家的热情做一个反馈，本文试着将 deepin-IDE 内部的一些实现方法进行分享，希望能够解答友友们的疑惑并得到积极的反馈。

本篇挑了大家关心的“调试”部分进行分享。需要说明的是，deepin-IDE 的调试功能是选用 DAP（Debug Adapter Protocol ）调试适配协议实现的，所以整体架构是围绕该协议搭建的，至于 DAP 具体是什么，让我们带着问号往下看。

什么是 `DAP` 协议

DAP 即调试适配协议( Debug Adapter Protocol )，顾名思义，它是用来对多种调试器进行抽象统一的适配层，将原有 IDE 和调试工具直接交互的模式更改为和 DAP 进行交互。该模式可以让 IDE 集成多种调试器变得更简单，且灵活性更好。

在 IDE 中的调试功能有许多小功能组成，包括单步执行、断点、查看变量值等，常规的实现方式是在每个 IDE 中去实现这些逻辑，且因为调试工具的接口不同，还需要为每个调试工具做一些适配工作，这将导致大量且重复的工作，如下图所示：

调试适配器协议背后的想法是标准化一个抽象协议，用于开发工具如何与具体调试器通信。这个思想和 LSP(Language Server Protocol)和 BSP(Build Server Protocol)类似，都是通过协议去统一相同功能在不同工具之间的差异性。其所处位置如下图所示，其中左边为不同的开发工具，右边为不能同的调试器，不同于开发工具和调试器直接交互的方式，DAP 将这些交互统一了起来，让开发工具和调试工具都面向 DAP 编程。

上图中的交互是通过协议进行，所以不会像通过 API 的方式存在语言限制，可以更好的适应调试器的集成。

DAP 如何工作

以下部分解释了开发工具（例如 IDE 或编辑器）和调试适配器之间的交互，包括具体的协议格式说明、交互流程等。

调试会话

开发工具有两种基础的方式和调试器进行交互，分别是:

【单会话模式】

在这种模式下，开发工具启动一个调试适配器作为一个单独的进程并且通过标准的std接口进行通信。在调试会话的结束时调试适配器就终止，对于当前的调试会话，开发工具往往需要实现多个调试适配。

【多会话模式】

在这种模式下，开发工具不会启动调试适配器，而是假定它已经在运行并且会在特定端口上侦听连接尝试，对于每个调试会话，开发工具在特定端口上启动一个新的通信会话并在会话结束时断开连接。

在与调试适配器建立连接后，开发工具和调试适配器之间通过基础协议进行通信。

基础协议

基础协议由两部分组成，包括头和内容(类似于 HTTP)，头部和内容部分通过“\r\n”进行分割：

【协议头】

协议头部分由字段组成，每个头字段由一个键和一个值组成，用‘:’（一个冒号和一个空格）分隔，每个头字段都以“\r\n“结尾。由于最后一个协议头字段和整个协议头本身都以 \r\n 终止，并且由于协议头是强制性的，所以消息的内容部分总是在（并唯一标识）两个 \r\n 序列之前。当前只支持一个协议头字段：

头字段名	值类型	描述
Content-Length	数字	这个字段是必须的，用来记录内容字段的长度，单位是字节。

协议头部分使用的是“ASCII”编码。

【内容部分】

内容部分包含了实际要传输的数据，这些数据用 JSON 格式来描述请求、响应和事件。内容部分用的是 utf-8 编码

为了有个具体的认识，这里举个简单的例子。在调试过程中，开发人员经常会使用到下一步操作，在 DAP 中其协议为：

Content-Length: 119\r\n
\r\n
{
   "seq": 153,
   "type": "request",
   "command": "next",
   "arguments": {
       "threadId": 3
  }
}

类型是“请求”，命令是下一步，参数部分可以携带多个，这里是用的线程Id。这个协议看着挺简单的，是吧？接下来就讲讲如何使用它。

使用方法

详细的使用方法这里就不涉及，因为用一个时序图就可以说明：

可以看到，初始化、请求、响应等必要的步骤都在图中。其中调试适配器可以理解为调试器的抽象，调试功能的最终执行者是由对应语言的调试工具实现的。

在 deepin-IDE 中的实现

在 deepin-IDE 中，调试功能的实现是结合 cppdap + debugmanager 实现的。

cppdap 是一款基于 C++ 开发的 SDK，基本实现了 DAP 的全量协议。 deepin-IDE 的客户端和服务端都是应用的该 SDK 进行开发，据此可以实现以下功能：

1.通信功能，包括服务端的 TCP 监听，客户端的 TCP 连接等；

2.DAP 协议的封装，并实现协议的串行化和解串行化；

3.提供注册回调功能，从而可以在回调内处理各种事件、请求等；

它的层级结构如下：

用 cppdap 可以减少客户端和服务端不少工作量，也统一了两边的协议数据。而 debugmanager 可以理解为调试器的抽象，包含所有必要的调试要素。整体结构如下：

左边是客户端，右边是服务端，内部实现如下：

客户端实现

客户端包含了两个个主要功能，一个是和 DAP 服务端进行交互，发送调试命令或处理返回的数据；另一个是将DAP 数据转换后显示到用户界面，并响应界面发送的事件。概括起来就包含业务模块、事件模块、DAP 模块和界面4个部分。

业务模块

业务模块包含了插件类、调试参数、调试管理类等，其中插件类负责插件加载、初始化、获取上下文等，调试管理类用来组合事件、DAP、界面几个模块。事件模块
事件模块包含两个子模块，分别是事件发送和事件接收，比如页面跳转事件、添加\移除断点事件等。 DAP 模块

DAP 模块基于 cppdap 开发，采用层级结构，底层是原始 DAP 协议封装，中间层是针对业务做的进一步封装，简化了向外提供的接口，最上层是对整个调试功能的整合，包括数据缓存、界面元素、命令收发。

界面部分界面模块包含堆栈界面、变量界面、断点列表、异步对话框等，用于 DAP 的数据展示。

如上图所示，灰色部分为 DAP 客户端的界面呈现。

服务端实现

服务端的功能分为两个部分，一个是基于 cppdap 实现命令的收发，另一个是与 gdb 交互，实现调试程序的启动、暂停、退出等一系列动作。

DAP

和客户端一样，服务端也是基于cppdap实现的通信和协议封装和解析。调试工具
和调试工具的交互是通过进程调用的方式实现，接收进程输出得到返回信息。如果调试工具本身支持 DAP 协议，则可以直接交互。

至此，本次的分享就到这儿啦！不知道你对 deepin-IDE 中的调试功能有所了解了吗？

温馨提示，deepin-IDE 还包含很多有意思的功能，如果大家感兴趣可以积极反馈，后续有机会再进行分享。

参考文档

debug-adapter-protocol

deepin-IDE 使用手册

内容来源：deepin社区

内容作者：deepin-mozart、toberyan

转载请注明出处

深度学习的历史与八卦

deepin 社区官方博客 — Fri, 01 Sep 2023 05:50:31 +0000

楔子

有这么一个说法，每多一个数学公式，读者就减少一半。深度学习想来也无法免俗，毕竟技术文章不免艰涩，而要完全绕过公式讲好深度学习与大模型，以臣妾微薄的实力实在是做不到啊。

因此，本文先歪歪楼，讲讲深度学习与大模型的历史与八卦，一方面是让大家稍微了解下技术发展的脉络，另一方面也是尝试挽救一下读者的欢心，毕竟历史八卦，人人都爱。

历史

说到神经网络的起源，一般都会追溯到沃尔特·皮茨（Walter Pitts）与麦卡洛克（McCulloch），其中皮茨起到了更主要的作用，而且更具传奇性。皮茨（见图1）于1923年出生于美国底特律的铁匠家庭，家庭教育以老爸的拳头为主，而在这种家庭环境里，他主要靠自学学会了拉丁文、希腊文、逻辑和数学。在12岁那年，皮茨看完了罗素与怀特海的大厚本《数学原理》，并向罗素写邮件附上了自己发现的一些问题，罗素不免大吃一惊，还回信邀请皮茨到剑桥大学读他的研究生。由于家庭与年龄原因，皮茨当然不可能成行，不过当三年后，罗素到美国芝加哥讲学的消息传到皮茨耳朵里时，他就离家出走，而且终其一生再也没有回去过。其后皮茨遇到了麦卡洛克，两人在数学、逻辑和神经网络上有着共同的看法，并一起努力，于1943年合作完成了知名论文《A LOGICAL CALCULUS OF THE IDEAS IMMANENT IN NERVOUS ACTIVITY》，在这篇论文中，他们用二进制逻辑门来表示神经元，而且证明了此模型可以实现任何经典逻辑，从而表明了神经网络的通用性，奠定了深度学习的基础，同时也建立了神经科学和计算机科学之间的交叉研究。高中未毕业的皮茨受到了数学家与控制论之父维纳的欣赏，破格进入麻省理工学院攻读博士学位，被引荐给了冯·诺依曼，而上述论文也成为了冯·诺依曼关于计算机架构的著名论文《First Draft of a Report on the EDVAC》所引用的唯一一篇文章。但是在其后，首先是维纳与皮茨等断绝了关系，然后科学家们又发现神经网络并不能解释一切生物感知现象，皮茨深感失望，于是烧掉了自己历经数年写作的博士论文，从此退出了科研界，并死于酗酒相关的病症。

图1 沃尔特·皮茨

我们要介绍的下一位是弗兰克·罗森布拉特（Frank Rosenblatt），他是感知机（Perceptron）的提出者（感知机在我们之前的文章“深度学习入门”里介绍过），并且于1958年在实验了50次之后，让IBM 704自行学会了识别打孔卡上的标记是在左侧还是在右侧。他认为，通过感知机可以不依赖人类的训练与控制，就能感知、识别和辨认周边的环境，其代表作是《Principles of Neurodynamics: Perceptrons and the Theory of Brain Mechanisms》。但是，当时罗森布拉特设计的感知机实际上是只有一层的神经网络，能力非常有限，相比之下，现代成熟的神经网络则有数十层，因此同样是人工智能专家的明斯基撰文指出了感知机的局限性，并使得相应的研究进入了低潮。直到在2004年，大家重新看到了神经网络的潜力，IEEE协会为此也专门设立了罗森布拉特奖。

在神经网络漫长的寒冬期，研究者相对较少，其中就包括了于1974年在其博士论文中提出了反向传播（backpropagation）的Werbos（并由于此贡献获得了IEEE罗森布拉特奖），还有于上个世纪八十年代提出了Hopfield 神经网络的Hopfield。

下面隆重登场的是深度学习之父，大名鼎鼎的杰弗里·辛顿（Geoffrey Hinton）。辛顿1986年发表的论文《Learning Representations by Back-Propagating Errors》，给出了通过反向传播学习表征的算法，于2006年其推出了深度学习（Deep Learning）的概念，为深度学习与大模型的大潮解开了序幕。

图2 杰弗里·辛顿

另一位深度学习的大佬杨立昆（Yann LeCun）在辛顿麾下求学后就职于贝尔实验室，并在1989～1993年间发明了卷积神经网络（CNN），可以用来解决手写数字识别（如MNIST）的问题。当时可没有GPU，那时CPU的性能也相当低下。

2012年是深度学习重要的一年。在这一年，辛顿和他的两个学生Alex Krizhevsky，以及Ilya Sutskeverz共同发布了AlexNet这个多层神经网络。这个神经网络用到了诸多的新技术，包括使用了ReLU作为激活函数，使用了CUDA利用英伟达的GPU来进行神经网络的计算，使用了dropout作为神经网络的一种优化方法等。AlexNet在知名的图像识别分类比赛ImageNet中一鸣惊人，它不仅获得了比赛的冠军，而且其错误率达到了16.4%，比当年亚军的26.2%低了将近10%，比2011年冠军的25.8%低了超过9%，几乎可以认为是降维打击。自此，深度学习名声大噪，大量研究人员都转向深度学习尝试完成计算机视觉等相关的人工智能任务。

下面深度学习的发展就顺畅了很多，2014年Ian Goodfellow推出了GAN，通过生成式对抗网络能生成逼真的图像甚至视频；2016年 DeepMind 推出了AlphaGo，其水平很快就远远超过了人类围棋冠军；同样在 2016年，何恺明等研究者推出了ResNet，它成为了包括大语言模型在内的各神经网络的通用技术，对应论文引用截止2023年上半年已经超过了17万，成为了深度学习领域引用最高的文章。

2017年是大模型关键技术transformer的诞生年，它是在《Attention is All You Need》这篇论文中被提出的，其后就成为包括BERT、GPT、T5等大语言模型使用的框架，而且跨界到了计算机视觉领域，形成了ViT等新的研究方向，几乎成了一统江湖的标准模型。

2018年是深度学习三巨头辛顿、杨立昆与约书亚·本吉奥（Yoshua Bengio）的收获之年，他们因为在深度学习方面的诸多成就与影响力获得了ACM图灵奖，这项计算机科学领域的最高奖。在接下来的几年，深度学习的各项研究成果仍然难以大规模落地，诸多深度学习相关的公司持续烧钱，很多人认为这一波人工智能的热潮马上又要过去了。

让我们快进到2022年，上半年以stable diffusion为代表的图像生成模型风靡一时，而到了下半年的十一月底，以ChatGPT为代表的大语言模型横空出世，其知识广度、推理能力与多轮对话能力使得它成为了历史上最快达到一亿用户的产品，重新点燃了人工智能产业化的火炬，并使得业界的诸多大佬认定它是划时代的产品，其影响深远，延续至今。

图3 DNNResearch团队

顺便说一句，GPT系列大模型的出品者是OpenAI，而OpenAI的首席科学家就是之前提到过的Ilya Sutskeverz。在2012年AlexNet一飞冲天后，多个大厂邀请辛顿等三人加入，于是辛顿团队成立了一个名为DNNResearch的公司，公司仅有他们叁，公司唯一的目的就是被大厂整体收购。竞拍的公司包括谷歌、百度、微软与DeepMind，随着竞拍价格的逐步走高，微软与DeepMind首先被淘汰出局，谷歌与百度均出价到了4400万美元。辛顿当晚暂停了竞拍，第二天早上便决定公司被谷歌收购。Ilya Sutskeverz在其后做出了诸多贡献，包括首创seq2seq（大语言模型的前身），参与深度学习框架Tensorflow与AlphaGo的开发等，最终于2015年加入OpenAI，成为了GPT等系列产品的核心技术人物。

八卦

关于深度学习之父辛顿，还有很多不少八卦，其家族还与中国有着不少联系。

从头说起，George Everest是十九世纪英国的大地测量工作者，其主要的工作地域都在印度，他和其前任测量了从喜马拉雅山到印度次大陆最南端科莫林角11.5度的经向弧，由于这些贡献，珠穆朗玛峰（Mount Everest）以他的名字命名。George Everest有一个侄女婿名为乔治·布尔（George Boole），也就是著名的布尔代数的发明者，现代计算机所使用的逻辑与、或、非等运算均来自于他。

乔治·布尔的小女儿艾捷尔·丽莲·伏尼契（Ethel Lilian Voynich）则是知名的《牛虻》的作者，这本书描写的是19世纪意大利爱国者反对奥地利统治者的斗争，是风靡一时的革命书籍，在苏联和中国都拥有广大读者。

乔治·布尔的大女儿玛丽（Mary）则嫁给了一个姓辛顿的数学家，他们有一个孙子威廉·辛顿（William Hinton），以及孙女琼·辛顿（Joan Hinton），不过在中国，他们一般被称为韩丁与寒春。寒春是芝加哥大学核子物理研究所的研究生，也是曼哈顿计划中少数的女科学家之一，在洛斯阿拉莫斯（Los Alamos）武器试验室做费米的助手，其后反对核战争，并于1948年来到中国，进入延安，投身中国革命，并与阳早（Erwin Engst）结婚，成为了奶牛专家。现在在北京还留有他们的工作成果，那就是北京市昌平区沙河大学城农机院的学农基地，寒春与阳早均为农机院学农基地的创办人，时至今日，每年仍然有大量的北京中学生来到学农基地参加学农实习（笔者的小孩有幸成为其中的一员）。寒春和阳早把大部分生命都奉献给了中国的事业，并最终在中国去世。2004年8月，中国开始实施“绿卡”制度，寒春成为了第一个获得中国“绿卡”的外国人。

图4 阳早与寒春

玛丽的另一支当然就是深度学习之父杰弗里·辛顿了，他是玛丽的曾孙，因此比寒春、韩丁晚一辈。当然，他们之间并没有直接联系。

深度学习的历史与八卦到此告一段落。下面，我们又将步入正轨，重新来讲讲产品与技术了，咱们下次再见。

走进大模型

deepin 社区官方博客 — Thu, 24 Aug 2023 02:02:31 +0000

应用大模型

AIGC 是基于大模型的，而大模型的基础是深度学习。上一篇文章对深度学习进行了初步介绍，首先是深度学习的神经元起源，引发了基于线性函数的模拟，又因为线性函数无法习得逻辑异或，因此引入了非线性的激活函数，再通过三层神经网络给出了MNIST手写数字识别的模型，接着又介绍了神经网络是如何通过数据与反向传播来学习与调整参数的，最后给出了神经网络的分层结构。

大模型的直观应用当然首先体现在包括ChatGPT、文心一言、讯飞星火等问答型产品的使用上，另一方面也体现在编程上，在此先给出大模型的编程应用。以下使用的模型、库与样例均来自于Hugging Face。

图1给出了基于大模型的英中翻译代码与运行结果。从图1中可以看到，真实的翻译代码只有14、15两行，其逻辑是使用了Helsinki-NLP的opus-mt-en-zh模型，其中mt代表机器翻译（machine translation）、en和zh分别表示英文和中文。从图1中同样可以看到，翻译结果相对还是比较准确的。

图1 基于大模型的英翻中

图2给出了基于大模型的文本情感分析的代码与运行结果。从图2中可以看到，实际有用的代码也仅需14、16两行，而且这次没有指定具体模型，只给出了需要text-classification这种模型。代码运行结果是认为文本情绪是负面的（NEGATIVE），准确度大概是90.1546%，这显然是符合实际的，因为文本是对商家发错货的抱怨。

图2 基于大模型的文本情感分析

图3给出了基于大模型的问答。这次的代码稍多一点，但实际的代码也只有三行。第14行给出了需要一个问答（question-answering）的大模型，但是没有指定大模型的名字，第15行是提问的字符串“What does the customer want”，即用户到底想要什么。第16行则使用上述文本作为上下文，提问字符串作为问题，传给问答大模型获取答案。从运行结果看来，答案还是蛮靠谱的。

图3 基于大模型的问答

当然，基于大模型的程序还有很多，但是从上面三个例子已经可以看出，基于大模型可以写出简短而强大的自然语言处理的程序，下面让我们走进大模型，看看它究竟是如何做到这一点的。

走进大模型

大模型在自然语言处理领域里大放异彩，因此首先需要了解自然语言的特点。

自然语言的显著特点（也是难点），那就是词与词之间有着广泛的关联。比如下面两句英文：

Go to the bank to get some money.
Go to the bank to get some water.

只有看到每一句的最后一个词，才能分辨出 bank 到底是银行还是堤坝。再比如下面这两句中文：

今天太冷了，能穿多少穿多少。
今天太热了，能穿多少穿多少。

整句话唯一不同的就是冷与热这两个字，但也就是这句话的一字之差，就导致了整句话的意义完全不同了。

因此，自然语言处理的关键点就在于如何能准确地判断词与词之间的关系，如果能准确地知道所有词之间的关系，那即使缺了一个词，也能根据关系推出缺的词应该是什么词。当下处理这一问题的主流技术是transformer，这个词不好翻译，主要因为它和变形金刚的英文一模一样。transformer的核心概念是注意力（attention），即每个词到底在注意其它的哪个词，或者说哪些词之间有什么关系。

注意力具体由以下关键概念组成：

每个词（实际上是词元，token）均有对应的 q/query（查询）、k/key（键值）与 v/value（值）这三个矩阵变量
q[i]用来查询本词（i）与其它词（j）之间的注意力
k[j]是词j回应查询的键值，具体是q[i]与k[j]相乘后缩放，接着用softmax激活函数处理，再乘以v[j]，这就得到了词i针对词j的注意力att[i,j]。
词i的对应输出为计算得到的注意力之和，即 y[i] = att[i,1] + att[i,2] + … + att[i,n]
注意力可以有多个（multi-head），每个注意力可以关注不同的方向，例如有的注意力关注的是词与词之间的意义，有的关注的是押韵，等等

图4给出了一个句子中各个词注意力的计算过程。

图4 注意力计算过程

句子是“小明、小刚、小红是小强的朋友，小明是…”，当前的词是“小红”，序号是3，可以看到小红的q值与每个词的k值相乘之后再用softmax处理（缩放操作在这里省略了），接着再与每个词的q值相乘，最后相加即可得到序号为3的输出。

那么这些k、q、v 等的值如何确定呢？当然是通过上一篇文章里提到的反向传播进行学习的，那反向传播学习自然语言的正确输出是什么呢？在大语言模型中，其训练手段是使用大量的高质量语料，将词语按序逐批输入大模型，以原句子中的下一个词或者特意被空缺出来的词为正确输出来学习的。例如在上面的句子中，大模型在输入了“小明、小刚、小红是小强的”之后，应该能计算输出“朋友”这个词，如果输出错误，则通过反向传播调整各个参数。也就是说，大模型就是根据一个词之前的词或者周围的词是什么来计算出这个词的，这就是大模型的理论基础和学习方法。

注意力虽然是大模型的核心概念，但除此之外，大模型还用到了其他技术，它们包括：

第一步需要将词转为数值向量（vector）的嵌入层（embedding），这也是现在很火的向量数据库的那个向量，向量数据库就是用来查询哪些文本向量比较相似，从而提取出对应的文字材料的
给词向量加上含位置信息的位置编码，以分辨出词的先后顺序，显然“我爱你”与“你爱我”的意义截然不同，因此词序是很重要的，而注意力本身并没有用到词序
在注意力层之后的残差处理与归一化处理，技术原理并不难，感兴趣的读者可以看参考资料

现在我们已经对大模型的主要技术原理有了粗浅的了解，下面来看看深度学习与大模型的特点。

大模型的特点

从对深度学习以及大模型的初步应用与原理了解，其实我们已经可以得出一些结论。

首先，深度学习的算法模型是神经网络及其节点上的参数/权重构成的，深度学习是端到端的机器学习，它不用由人类专家预先设计特征算法，例如不用苦思冥想怎么设计一个提取图像中线条的算法，只需要用大量的高质量标注数据对其进行投喂，就有可能最终训练出质量不错的神经网络（中的各个参数）来。

其次，它是一个黑盒子，因为没有特征设计，因此这么多数值构成的神经网络，它为什么能达到最终的目标，为什么某个参数就必须是最后训练出来的那个数值，为什么有的时候识别会失败或者生成会出错，是否可以手工修改某些特定的参数使得其成功率上升，同时又不会导致原来成功的事例失败，这些问题在现阶段都是难以回答的，这就是深度学习的可解释性问题。

在ChatGPT之前，大模型其实也在发展，但是ChatGPT表现出来的多领域通用性和流畅性与之前的产品相比有明显的超越，所以造成了轰动。其后的GPT-4表现更为优异，在《Sparks of Artificial General Intelligence：Early Experiments with GPT-4》这篇论文里，微软团队给出了这样的一个示例：

提问：Can you write a proof that there are infinitely many primes, with every line that rhymes?
GPT4：Yes, I think I can,
Though it might take a clever plan.
I’ll start by noting Euclid’s proof,
Which shows that primes aren’t just aloof.
Assume we have a finite list,
Of primes, and that none have been missed.
Multiply them all together,
And add one, just to be clever.
The result will be a number,
That has no prime factors, oh wonder!
But every number has a prime,
That divides it, it’s just a matter of time.
So we’ve found a contradiction,
And our finite list needs eviction.
There must be infinitely many primes,
And that’s the end of my rhyming lines.

提问者让GPT-4写一首诗，来证明素数有无限多个，然后GPT-4很快就完成了这首诗，每两行押韵，而且用欧几里得的经典方法给出了证明。当然，在论文中还有很多让人印象深刻的例子，但是上面的例子已能说明GPT-4确实有了很强的能力。

GPT中的G表示生成（Generative），这表示它主要的工作方式是生成内容，内容在这里主要是自然语言文本。按照OpenAI首席执行官Sam Altman的说法，The most important difference between ChatGPT and GPT-4, is that the GPT-4 predicts the next word with greater accuracy，即 ChatGPT与GPT-4最大的差异就在于GPT-4在预测下一个词的准确度比ChatGPT更高。

GPT中的P表示预训练（Pretrain），即首先用大量语料训练出基础模型（foundation model），然后再用下游任务相关的语料进行精调（FT，即finetuning）。这些下游任务可能是文本分类、翻译、对话等等，这样就可以不用单独为某个特定任务从头训练了。我们可以把中学教育和通识教育看作是预训练，它为大学最终的专业选择，以及以后更细的工作分工打下了坚实的基础。反过来看，在小学年龄阶段没有上学可能会对以后的择业带来很大的限制，这也可以看成是大脑在应预训练的阶段没有进行有效的预训练导致的问题。

GPT中的T表示transformer，这个已经在上文中介绍了。

一般认为，GPT-4有更强能力的原因在于：

它提供了大量的高质量数据，原始数据有45T，清洗后的语料是570G，清洗比例接近1%，这是之前几乎没有团队做到的
数据中混合了大量的代码，原始数据中有830G代码，这一般被认为是推理能力提升的关键点之一，当然另一方面也大大提升了它的代码能力
展开了大量不同种类的下游任务，如生成、问答、脑暴、闲聊、摘要、分类、提取等等，以上两点也属于多样化工作，它为GPT4的通用性打下了基础
使用了基于人工反馈的增强学习（RLHF）方法，召集了40个众包团队，撰写了数十万的提示数据以对齐主流价值观

一般认为，大模型的表现之所以如此智能，但是之前的小模型神经网络却那么智障，其原因可能在于涌现（emergence）。涌现可以简单认为是单个个体微观上简单的行为，在宏观上大量复合呈现出难以预料的规律。比如每只蚂蚁其行为其实是挺简单的，但是一群蚂蚁在一起，就可以表现出复杂的规律。又如每个神经元的行为都很简单，但是这么多神经元聚集在一起，就形成了聪明的人类大脑，这也算是一种涌现。

涌现最直观的例子可能就是康威的生命游戏（Conwey’s Life Game）了，这个游戏是在一个网格平面（类似围棋棋盘）上发生的，每个个里要么有一个存活的细胞，（用黑色格表示），要么就是一个死亡的细胞（用白色格表示），其规则也很简单，只有以下四条：

当前细胞存活时，当周围存活细胞<2时，该细胞死亡（模拟生命数量稀少）
当前细胞存活时，当周围有2个或3个存活细胞时，该细胞保持存活
当前细胞存活时，当周围存活细胞>3时，该细胞死亡（模拟生命数量拥挤）
当前细胞死亡时，当周围存活细胞=3时，该细胞复活（模拟繁殖）

那么图5里的四个样式就表示绝对静止的细胞群体。

图5 康威生命游戏中绝对静止的细胞群体

对每个样式进行分析很快就会知道为什么它们会绝对静止。以第二个样式为例，其每个存活细胞周围都刚好有两个存活细胞，按照规则2，它们都应该保持存活。而任何一个死亡细胞周围都没有四个存活细胞，因此此样式将永远不变。

图6给出了震荡循环的细胞群体。

图6 康威生命游戏中震荡循环的细胞群体

按照康威生命游戏的规则，可以发现图6中的两个样式会演变几步之后又变成当前的样式。以第二个样式为例，其一共有左中右三个存活细胞。左侧与右侧的存活细胞附近只有一个存活细胞，因此按照规则1，会在下一轮死亡。中间的存活细胞附近有两个存活细胞，因此按照规则2，保持存活。同时又可以发现，中间的存活细胞上侧和下侧的死亡细胞由于其附近有三个存活细胞，因此根据规则4，在下一轮它们将复活。以此类推，样式会由横三转为纵三，又转回横三，永远震荡循环。

康威生命游戏有着远超过上述样式的复杂度，在宏观上甚至可以看到游走、巡回、扩张、凋零等多种细胞社群的样式，因此四条简单的微观规则就衍生出了让人事先难以预料的宏观样式上的复杂度，是涌现的一个生动形象的例子。

以ChatGPT与GPT-4为代表的大模型由于其使用了自然语言对话而引发了轰动，让普通人都能直观感受到大模型的魅力，但同时它作为一个基础设施，也提出了一个难题，就是它的编程接口是基于自然语言的，所以需要做所谓的提示工程（prompt engineering）。所谓提示工程，指的就是想让大模型好好干活，那就需要自己好好琢磨怎么和大模型好好说话。俗话说见人下菜，或者说见人说人话，见鬼说鬼话，那见了ChatGPT，当然就得说ChatGPT话了，不然它就没法理解问题，自然也没法给出好的回答了。Linux圈子里有Linus大佬的一句名言：“talk is cheap, show me your code”，中文翻译也很传神：“废话少说，放码过来”，俗一点的话那就是“少哔哔，秀代码”，但是自打GPT横空出世，以后可能就是“code is cheap, show me your talk”了，毕竟，给GPT一个提示，它可以还你百行代码。

不过神经网络毕竟是一种信息压缩，或说是一种函数拟合，因此中间肯定会有信息损失，或说是自己瞎想的填补空白，那就避免不了GPT一本正经的胡说八道，也就是所谓的幻觉（hallucination）了。幻觉是当前大模型应用的主要障碍之一，一般认为，大模型近期的发展将沿着消减幻觉、工具集成（即能使用外部工具）、多模态（即除了文本以外，也能理解和生成图形、语音、视频等内容）、垂直领域、类脑智能、具身（embodied）智能等方向发展。

深度学习入门

deepin 社区官方博客 — Mon, 21 Aug 2023 08:22:31 +0000

背景

从去年底以来，AIGC 炙手可热，多个业界大佬都认为 AIGC 会给整个产业带来一场革命，甚至所有的软件都会用 AI 重写。从历史上来看，人机交互方式的变革往往会将操作系统带入下一个世代，著名的例子如从命令行界面的 DOS 到键鼠图形界面的 Windows，以及带来触控界面的 iPhone，领创者都成为了世界顶级企业，带动了整个生态的发展。

从技术上来看，AIGC 是基于大模型的，而大模型的基础是深度学习，因此，为了在产品上结合 AIGC，首先从技术上首先需要对深度学习进行有深度的学习。

对深度学习与大模型的探索将由一系列文章组成，本文是系列里的第一篇，主要关注的是深度学习的技术入门探索。

从神经元开始

回溯历史，深度学习起始于向人类的大脑学习如何学习。人类大脑皮质的思维活动就是通过大量中间神经元的极其复杂的反射活动，因此不妨先看看神经元的工作机制。

图1 神经元结构

图1给出了神经元的大体结构，左边是神经元的主体，其输入是左侧的多个树突，其输出是右侧的一个轴突。只有当输入树突的信号足够强烈的时候，输出轴突上才会有信号产生。受此启发，就可以设计一个最简单的有两个输入x₁与x₂，以及一个输出y的线性函数来模拟单个神经元，引入阈值θ，当 w₁x₁ + w₂x₂ ≥ θ时，y为1（表示有信号），否则y为0（表示无信号）。其中w₁与w₂分别是x₁与x₂的参数或权重（weight）。

有了这个函数，下面来看看它究竟能做什么。按照逻辑主义的设想，数学可以通过逻辑推衍出来，那么不妨看看，上面的函数是否可以表征出基本逻辑运算，如与、或、异或等，在这里x₁、x₂与y的取值都只能是0或1。

对于逻辑与来说，只有当x₁与x₂都是1的时候，y才是1，否则y是0，容易尝试得到一组可能的w₁、w₂与θ，分别是0.5、0.5与0.7，如图2所示。

图2 逻辑与的线性函数图

图2中横轴为x₁，纵轴为x₂，从图2中可以看到，(1, 1) 点为实心圆，表示y为1，在(0, 0)、(0, 1)与(1, 0)都是空心圆，表示y为0，中间的虚线表示w₁x₁ + w₂x₂ = θ这条直线，只要这条直线能将(1, 1)点与其它点划分到不同区域，则显然就可以找到至少一组w₁、w₂与θ满足条件。基于同样的分析，容易知道逻辑或也可以找到对应的w₁、w₂与θ。但是对于逻辑异或来说，问题就严重了，显然无法找到满足条件的w₁、w₂与θ，如图3所示。

图3 逻辑异或的函数图

逻辑异或是当x₁与x₂中一个为0，另一个为1时y才为1，否则y为0，因此在图3中，点(0,1)与点(1,0)为实心圆，而(0, 0)与(1, 1)为空心圆，显然是无法找到一条直线将两个实心圆与两个空心圆划分在两个不同区域的。因此，上述最朴素的线性神经元函数无法表示逻辑异或，也就意味着有大量的运算无法通过上述线性神经元函数来进行。

引入激活函数

是否能改造上述函数，让它能支持所有运算，从而能承担学习的任务呢？至少，人脑肯定是能学会异或的。现在看来，主要是因为原始的神经元函数太线性导致的这个问题。因此，在深度学习中，就引入了非线性的激活函数（activation function），如图4所示。

图4 引入激活函数

在图4中，首先原函数被修改成了支持多个输入和多个输出的线性变换函数，这样就能处理更多种类的问题了。因为有了多个输入x₁、x₂…x_m与多个输出h₁、h₂…h_n，因此权重的下标也带有两个数字，以表示每个权重的作用，例如 w₁₂ 是输入x₂与输出h₁间的权重。还有一个特殊的权重b_i，它被称为偏置（bias），是一个待确定的常数项。这样，h就等于相应的x与w相乘后再加上b。例如，h_i = x_iw_i1 + x₂w_i2 + … + x_mw_im + b_i。经过线性变换后得到的输出h₁、h₂…h_n只是中间过程的输出，在之后，还需要加入一个非线性的激活函数的处理，以得到最终的输出y₁～y_n，如图4所示。

在具体激活函数的选择上，比较常见的有 softmax、sigmoid 与 relu 等。其中 softmax 函数是多分类问题最常用的输出激活函数（多分类问题指的是一个问题有多个确定个数的可能答案，例如是/否问题是二分类问题，而分辨一个手写阿拉伯数字是哪个数就是一个十分类问题，因为可能答案有0～9一共十个），softmax也是包括ChatGPT在内的大模型使用的输出函数。使用了激活函数以后，神经网络就可以学习到所有函数了。下面来看一个经典的神经网络的例子，手写数字识别问题，或MNIST问题。MNIST涉及的手写数字在网上是公开的，如图5所示。程序员们可以先想想，如果自己来写一个程序识别手写数字会怎么写。可以识别手写数字的（一个）神经网络的结构如图6所示。

图5 MNIST手写数字样例

图6 能识别手写数字的神经网络

可以看到图6的神经网络一共用到了三个线性变换，并使用了两个sigmoid 激活函数，以及最后的softmax激活函数，因此可以说这个神经网络是三层的。神经网络的输入（x₁～x₇₈₄）是一个长度为784的数组，其实就是一个28x28=784的手写数字的黑白图像。神经网络的输出（y₁～y₁₀）分别代表了0～9的阿拉伯数字，这是一个典型的十分类问题，因此使用softmax也是非常自然的。

图6中的神经网络一共有(784x50+50) + (50x100+100) + (100x10+10) = 45360个参数，对比ChatGPT上千亿个参数，这显然是一个微模型，但是它的识别能力却可以达到92.53%，也就是说一万个手写数字，它能正确识别出9253个来。那问题就来了，这45360个参数是怎么来的呢？肯定不能是随便什么 45360 个数都能带来这么高的识别率的，要解决这个问题，就需要看看神经网络是怎么学习的了。

神经网络的学习

在上面已经看到，神经网络里有大量的参数。在最开始，这些参数会被随机分配一些数字（当然如何随机分配也有讲究的，简洁起见，此处先不提），此外也需要准备大量的数据，这些数据一般是多个输入输出的对(x, t)。例如在上面的手写数字识别问题中，输入x就是一个28x28的手写数字图像，输出t就是这个图像对应的0～9中的一个数字。这些数据会被分成训练集与测试集。训练集中的数据用来训练神经网络，让神经网络中的参数最终达到正确的值。测试集中的数据用来测试训练后的神经网络，对比看训练后的神经网络在新的数据下得到的结果是否正确。

神经网络的训练过程可以大体分为下面几步：

对训练集中的输入输出对(x, t)进行如下处理
将x输入到神经网络中，计算得到y
将y与正确的输出t进行运算得到损失L，损失的计算函数一般是均方差或交叉熵，前者针对的是回归问题（连续函数拟合），后者针对的是分类问题
根据L调整神经网络的参数，调整的方向是减少L，调整的方法是下面要讲的反向传播

图7给出了神经网络训练的过程。

图7 神经网络训练过程

一旦训练完毕，使用的时候就不需要正确输出t，也不需要计算损失L和调整神经网络的参数了，这个过程被称为推理（inference），如图8所示。

图8 神经网络推理过程

顺便说一句，图中的深度神经网络与神经网络结构是一样的，但是层数较多，因此被称为深度神经网络。

下面，再来看看神经网络究竟是怎样通过损失L来调整网络参数的。最简单，也是最直观的方法就是将每个参数都稍微调大或者调小一点，看L会如何变化，如果L变小，则保持此参数的调整，如果L变大，则将此参数反过来调整。以上即正向调整法，思路清晰，操作方法简单，但是计算量极大，因为每调整一个参数就要重新计算一遍y与L。

另一种方法就是现在主流的反向传播（BP，backpropagation）法，此方法类似系统发生故障时的根因分析，首先分析最后一层的参数是怎样影响到L的，然后分析倒数第二层的参数是如何影响到最后一层的输入的，如此类推。在数学上，其实就是计算L对某个特定参数w的（偏）导数，因为导数就代表了w的变化会导致L如何变化。根据链式求导法则，L对w的导数等于L对中间变量h的导数乘以h对w的导数，前者相当于计算最后一层参数的导数，后者相当于计算倒数第二层参数的导数，两者相乘即为L对导数第二层参数的导数。

下面主要通过求导来展示反向传播，如果希望更直观一点，可以阅读计算图相关的资料。假设真实函数是y=2x+1，则待求函数为wx+b（当然w与b的真实值应该是2与1）。下面通过一组数据（训练集）来通过反向传播逐步计算更新w与b，看看它们否会逐渐逼近2与1。

由于这是一个回归问题，因此使用均方差(y-t)< sup>2< /sup>/2作为损失L的函数，显然L对y的导数是y-t，参数更新使用经典的梯度下降法（SGD），即参数新值=参数旧值 - 学习率x(L对参数的导数)，梯度下降有一个粗糙但是直观的理解，那就是学习应该向着导数（梯度）相反（下降）的方向走，在这里学习率这个参数设为0.01。

首先，将w与b随机化为0.5与0.6。

假设第一个训练对为(0, 1)，则 y = wx + b = 0.5·0 + 0.6 = 0.6，L对w的导数=L对y的导数乘以y对w的导数=(y-t)·x=(0.6-1)·0=0，L对b的导数=L对y的导数乘以y对b的导数=(y-t)·1=-0.4。则w的新值为w-0.01·0=0.5，b的新值为b-0.01·(-0.4)=0.604，显然新的w与b比原来的更接近(2, 1)。

若第二个训练对为(1, 2.9)（本来应为1与3，但是增加了一点误差干扰），可以以同样的方法得到新的w为0.51796，而新的b为0.62196，显然比上一对w与b又接近了2与1一点。

实际上，若继续增加2x+1附近的数据，可以发现到了十几对训练数对之后，w与b即可相当接近2与1了。

以上例子是为了直观感受反向传播的计算而给出的，实际上这种线性函数的回归可以通过数据集基于矩阵一次性算出来，而且训练本身也要考虑收敛的问题，因此实际的深度学习会更复杂一些，但是原理是类似的。

总地来说，深度神经网络是由多个层组成的，每一层均有前向（forward）推理的函数，用来从输入计算得到输出，这个过程即为推理。每一层也有反向（backward）传播的函数，用来从后一层传来的导数计算得到本层向前一层传递的导数，并同时更新本层的参数。如果是训练，则需要在最后一层再加上一个输入为t与y的损失层，输出为L，如图9所示。

图9 多层神经网络结构

通过以上几乎标准化的神经网络层，深度学习的研究者就可以像搭积木一样对多个层进行排列组合，得到多种多样的深度神经网络，并首先通过反向传播训练出神经网络的参数，继而使用神经网络进行推理应用了。

DDE-Control-Center 自启动管理插件项目文档

dde 自启动管理插件开发小组博客 — Mon, 14 Aug 2023 06:00:00 +0000

队员：复旦大学朱元依、沈扬、朱俊杰
指导老师：张亮、陈辰
企业导师：王子冲

本项目为2023年操作系统大赛企业赛道赛题。

项目链接：DDE 控制中心自启动管理插件 github仓库

1 摘要

Deepin(原名Linux Deepin)致力于为全球用户提供美观易用，安全可靠的Linux发行版。该系统由深度科技自主开发，提供了美观易用、极简操作的桌面环境，主要由桌面、启动器、任务栏、控制中心、窗口管理器等组成。其中，控制中心是Deepin桌面环境的核心组件之一，它是用于管理和配置操作系统各种设置的集成工具。然而，在该控制中心中，并未对用户提供自启动项提供的便捷管理界面。在本项目中，我们为Deepin操作系统中自启动项的修改功能编写了简洁易用的控制中心插件，将自启动管理的系统功能集成到了控制中心中。该插件以单独的仓库提供，并能够单独构建，一键植入Deepin控制中心中。

2 需求分析

最终用户对自启动权限的管理目前只能通过dde-launcher（启动器/“开始菜单”）的右键菜单进行管理，而控制中心作为控制系统的门户应用反而缺少此功能。

用户需求

在官方发布的deepin23-Beta版本中，对于用户程序与系统程序的自启动管理方法为：找到应用的可执行程序（通常为.desktop）类型的文件，通过右键打开功能菜单的方式设置为开机自启动。但由于操作系统自带的应用程序界面中所有程序都会被展示到，所以当操作系统中应用程序过多的时候用户很难统计到那些程序被设置成了开机自启动，同时对于用户不想参与管理的应用也会展示在应用菜单中。因此我们对于本项目开发所面向的需求是在控制中心（deepin-control-center）中在不影响原有插件所提供的设置服务的基础上，为用户提供一个额外的插件用于管理开机自启动软件，同时插件可以满足用户自行选择需要手动维护的自启动程序，对于用户希望自己管理是否自启动的软件显示在面板上可以对是否自启动进行开关，用户不希望管理的软件默认不自启动不显示到面板；面板也可以提供添加和删除的功能让用户挑选出自己想要在面板上操作的应用。

功能需求

deepin作为国产开源的深度Linux桌面系统，不仅为用户提供了人性化、个性化以及对于中文等语言有良好支持的操作系统体验，也为Linux的开发者与学习者提供了控制中心（dde-control-center）与任务栏（dde-dock）等桌面控件的开发者接口与插件注入接口。除了可以不断的扩展完善用户需求与用户体验外，deepin深度桌面在操作系统学科的教学与深入理解方面也带来了很多的可能性与创造性。因此作为OS大赛的参与团队，我们不仅是在希望我们的开发会对deepin项目的完整性、deepin用户的体验感上带来一些帮助，同时也想通过我们自己的努力在学生的视角让操作系统的教学与后续学习有一个优秀的案例和一些开发相关的经验总结，使得我们理论层面的操作系统教学可以有更大的实践空间。

2.1 当前方案

目前已有的自启动管理方法是在开始菜单中对菜单中所展示应用软件单独进行自启动的设置。具体的方法是对所希望设置自启动项的应用软件选中后右键，点击“设置开机自启动”即可在每次开机时自动打开该应用软件。

然而，这种方法有两大明显的缺陷：（1）无法向用户展示所有的自启动项设置（2）大批量的自启动项修改极其不便。由此，催生了控制中心自启动管理插件的需求。

2.2 插件需求

为了完成控制中心插件，我们对需求进行了更细致的刻画。经过总结后，插件的需求主要分为三条：

1、完成一个控制中心插件，能够展示当前所有开机启动项的列表； 2、能够在插件中，通过用户界面的交互来管理（添加、删除、启用、禁用）开机启动项； 3、插件以单独的仓库提供，并能够单独构建，不需要合并入 dde-control-center 项目。

其中，第一条需求是该插件的基础。自启动项的列表一方面为用户提供了清晰的展示界面，另一方面也是程序与用户交互，获取修改操作信息的基础。第二条需求总结了该插件需要支持的功能，即添加、删除、启用、禁用，这些功能需要在前端设计对应的交互界面，同时在后端设计对应的操作接口，调用系统接口以修改自启动设置。第三条需求与系统发布相关。目前最新的稳定发布版本是Deepin V23 Beta，而官方版本已经在发布，若修改源码统一编译控制中心，会需要对当前已发行的操作系统版本进行修改，较为不便。故需要单独编译该插件，并将其装载到系统中的插件接口中。

3 相关资料调研

3.1 Deepin开机自启动系统设置

Deepin系统通过检测固定的目录，检测自启动项。通过放置应用程序的.desktop文件在其中一个自动启动目录中，系统可以检测到该应用程序的自启动设置。通过修改.desktop文件中的对应字段，可以修改对应应用程序的自启动设置。

3.1.1 自启动目录

在“desktop base directory specification”中的“Referencing this specification” 部分进行定义了自动启动目录是 $XDG_CONFIG_DIRS/autostart。

如果同一文件名位于多个自动启动目录下，只应使用最重要目录下的文件。

示例：

如果未设置$XDG_CONFIG_HOME，用户主目录中的自动启动目录为~/.config/autostart/。

如果未设置$XDG_CONFIG_DIRS，系统范围的自动启动目录为/etc/xdg/autostart/。

如果未设置$XDG_CONFIG_HOME和$XDG_CONFIG_DIRS，并且两个文件/etc/xdg/autostart/foo.desktop和 ~/.config/autostart/foo.desktop存在，那么只有文件~/.config/autostart/foo.desktop将被使用，因为~/.config/autostart/比/etc/xdg/autostart/更重要。

3.1.2 应用程序的`.desktop` 文件

一个应用程序的.desktop文件必须符合"桌面入口规范"中定义的格式。所有关键字应按照定义进行解释，但以下情况除外，以便考虑到位于自动启动目录中的.desktop文件不会显示在菜单中。

`Hidden`关键字

当.desktop文件的Hidden关键字设置为true时，该.desktop文件必须被忽略。当多个具有相同名称的.desktop文件存在于多个目录中时，仅应考虑最重要的.desktop文件中的Hidden关键字：如果其设置为true，则其他目录中具有相同名称的所有.desktop文件也必须被忽略。

`OnlyShowIn`和`NotShowIn`关键字

OnlyShowIn项可以包含一个字符串列表，用于标识必须自动启动此应用程序的桌面环境，其他桌面环境不得自动启动此应用程序。

NotShowIn项可以包含一个字符串列表，用于标识不得自动启动此应用程序的桌面环境，其他桌面环境必须自动启动此应用程序。

这两个关键字中的一个，要么是OnlyShowIn，要么是NotShowIn，可以出现在单个.desktop文件中。

`TryExec`关键字

带有非空TryExec字段的.desktop文件如果TryExec关键字的值与已安装的可执行程序不匹配，则不得自动启动。TryExec字段的值可以是绝对路径，也可以是没有任何路径组件的可执行文件名。如果指定了没有任何路径组件的可执行文件名，则会搜索$PATH环境以找到匹配的可执行程序。

注意事项

如果通过在系统范围的自动启动目录中安装.desktop文件来自动启动应用程序，则个人用户可以通过在其个人自动启动目录中放置具有相同名称的.desktop文件来禁用此应用程序的自动启动，并在其中包含Hidden=true关键字。

3.2 控制中心插件开发

V23控制中心特性

1、V23控制中心只负责框架设计，具体功能全部由插件实现； 2、V23控制中心支持多级插件系统，支持插件插入到任意位置中； 3、高度可定制，可定制任意插件是否显示，若插件支持，可定制任意插件内容是否显示。

V23控制中心插件安装路径说明

1、控制中心会自动加载翻译，翻译目录需要严格放置在/${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_DATAROOTDIR}/dde-control-center/translations下，控制中心会自动加载，同时，插件的翻译和名称也有要求，命名为${Plugin_name}_{locale}.ts，locale就是多语言的翻译，翻译文件必须控制和插件名称相同； 2、控制中心的so应该放置在/${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTA；LL_LIBDIR}/dde-control-center/modules下，请使用构建系统的提供的gnuinstall路径，上面举的例子是cmake，mesonbuild也有自己的逻辑。

V23控制中心开发接口说明

1、ModuleObject类用于构建每个页面元素，其是插件的核心； 2、PluginInterface类用于规范插件信息，每个插件必须提供一个`ModuleObject对象。

标准开发流程示例

1、继承PluginInterface，实现其虚函数； 2、实例化一个根模块，根模块在初始化时不允许有耗时操作，若有耗时操作，应继承ModuleObject然后实现active方法，将耗时操作放入其中； 3、若根模块的子项是横向菜单列表，则可使用List储存其基础信息，继承或使用HListModule类，然后循环使用appendChild方法将菜单添加到根模块中； 4、若根模块的子项是纵向菜单列表，则可使用List储存其基础信息，继承或使用VListModule类，然后循环使用appendChild方法将菜单添加到根模块中； 5、以此类推，具体的某个子项菜单同样再次添加菜单列表，直到菜单列表的子项为PageModule时为止； 6、准备一个以上的Module继承自ModuleObject，并实现其page()方法，然后添加到PageModule中，注意，page()方法中需返回新的QWidget对象； 7、当某个菜单为PageModule时，使用其appendChild方法将上方的Module添加到其子项中，此时，控制中心会根据page的大小添加滚动条，并将多个page进行垂直排列进行显示。PageModule持支嵌套，并且其有默认边距，如果嵌套使用，嵌套的PageModule边距建议设置为0； 8、若某个VListModule或PageModule页面需要附加按钮时，可调其子项ModuleObject的setExtra，该ModuleObject的page提供按钮，这样该ModuleObject将显示在VListModule或PageModule页面的最下方。

4 系统框架设计

4.1 项目组织方式

类图

项目文件组织

.
├── CMakeLists.txt
├── include
│ ├── interface
│ │ ├── ...
│ └── widgets
│ ├── ...
├── misc
│ ├── ...
├── shell.sh
├── src
│ ├── frame
│ │ ├── ...
│ ├── interface
│ │ ├── ...
│ ├── plugin-selfstartup
│ │ ├── operation
│ │ │ ├── ...
│ │ └── window
│ │ ├── ...
│ └── widgets
│ ├── ...
└── translations
 ├── ...(translation files)
 ├── desktop
 ├──...(desktop translation files)

4.1 总体思路与系统框架

4.1.1文件框架思路

通过阅读dde-control-center的源代码，src部分为插件的实现以及实现代码复用所存在的框架代码，代码的插件部分在src/plugin-selfstartup目录，分为operation和window部分，其中windows部分主要负责控制中心自启动项目的界面构成，operation部分负责参与控制中心对系统文件与配置的控制。translation文件夹为控制中心（dde-control-center）提供了不同语言环境下的支持，通过识别系统的语言环境选择展示到面板不同的语言。include与misc为项目注册到控制中心所必须包含的编译依赖文件。

4.1.2 设计思路

我们在初赛中已经完成了通过注册到dde-dock实现的自启动插件，对于插件的界面以及界面上按钮对应的功能已经有了一个大致的构想，但由于dde-dock的插件是一个较为独立的结构，而dde-control-center里面的每一个插件都需要往控制中心里注册一个module并且通过rpc方法与dde-application-manager进行远程服务的交流，因此在实现细节上dde-control-center插件和dde-dock插件有着很大的区别。

用户逻辑方面，我们首先在控制中心实现了管理自启动应用的面板，对于添加到维护列表的应用都会被展示到面板上，对于每一项应用都会提供Enable/Disable的选择按钮和Delete的删除按钮，用于管理是否开机自启动与不希望维护改应用的删除。同时在面板有一个添加按钮，用户点击后会打开文件对话框，用户可以自行从中选择自定义路径的应用程序添加到插件维护的列表中。

插件运行逻辑方面，分别有添加、删除、开启/关闭（反转）逻辑，分别思路如下：

添加逻辑：用户在点击添加按钮后会获取该文件的路径并读取FileInfo，AddButtonWidget发送requestCreateFile信号携带参数Category名称与FileInfo到Worker中；Worker在/home/user/.config/autostart文件下判断是否存在一个相同的应用信息，如果不存在则创建一个原.desktop文件的副本并且添加一行Hidden=false字段，把应用信息存到App结构体中，同时调用Worker中对应的Category的添加函数传入赋值好的App，Category在内存中同步一份自启动应用信息，最后更新前端页面。
删除逻辑：在用户点击应用对应行的删除按钮后获取到AppID，通过getAppById得到App信息后发送requestDelUserApp信号到Worker，Woker找到autostart文件夹中对应文件并将其删去，同时把App在对应的Category中移除，最后更新前端页面。
反转逻辑：在用户点击对应行的打勾按钮后想获取到AppId，通过getAppById得到App信息后发送反转请求到Worker，Worker读取磁盘中autostart里对应.desktop文件文本找到Hidden字段并将其反转，同时调用Category把内存中App结构体的Hidden成员反转，最后更新前端页面。
启动逻辑：插件启动的时候会调用Category的getAppItem函数，该函数从autostart文件夹中逐文件读取信息存在App结构体中，封装到m_appList作为初始化时参与维护的应用程序，前端从m_appList中把应用名称以及是否自启动信息列举到页面

4.2 类功能说明

operation部分

├── defappmodel.cpp
├── defappmodel.h
├── defappworker.cpp
├── defappworker.h
├── mimedbusproxy.cpp
├── mimedbusproxy.h
└── qrc

operation部分是插件的后端部分，对于控制中心的每个插件都有Model，Worker和DBusProxy三个部分：

Model：Model部分通过继承QObject注册到QT的项目中，私有变量Category实现了自启动信息在内存中的一个副本用于前端的交互。
Worker：Worker部分提供了插件对文件系统的操作。由于操作系统对于开机自启动的支持在于把对应的.desktop文件拷贝到/home/user/.config/autostart中并设置Hidden=false，因此对于自启动应用管理的插件必须要对文件的读写提供支持，该支持由Woker部分实现。
DBusProxy：由于插件要注册到控制中心并且对应用进行管理，因此需要向运行中的应用程序管理服务（dde-application-manager）进行交互，管理服务提供了rpc的调用接口，插件通过DBusProxy部分向管理服务发起远程请求。

window部分

├── selfstartup.json
├── selfstartup.cpp
├── selfstartupdetailwidget.h
├── selfstartupplugin.cpp
├── selfstartupplugin.h
└── widgets
├── addbuttonwidget.cpp
├── addbuttonwidget.h
├── category.cpp
└── category.h

window部分是插件的前端部分，由Plugin，Detailwidget，Addbuttonwidget和Category四个部分：

Plugin：Plugin部分构造了自启动程序插件。包括插件接口的初始化，一级页面的初始化和二级页面的初始化。
Detailwidget：Detailwidget部分构造了自启动程序插件的 app条目。包括app条目的外形、位置，app条目的增删改查操作，以及与worker和model的交互操作（通过信号和槽函数实现）。
Addbuttonwidget：Addbuttonwidget部分构造了自启动程序插件的加号按钮。包括加号按钮的外形、位置，新增app的弹窗显示，新增app的路径处理，以及与worker和model的交互操作（通过信号和槽函数实现）。
Category: category部分为磁盘中autostart文件夹中重要信息在内存中的拷贝，用于插件的窗口部分直接获取到该文件夹中.desktop类型文件的重要字段展示到界面。

4.3 实现描述

4.3.1 DefAppModel

名称	功能
DefAppModel	Model构造函数
~DefAppModel	Model析构函数
getModSelfSetUp	返回SelfSetUp内存Category

4.3.2 DefAppWorker

名称	功能
DefAppWorker	Worker构造函数，连接Worker和Model
DefaultAppsCategory	枚举类，用于实现插件的可扩展性，实现对不同类型软件的分类，默认状态为只有SelfSetUp类
active	向应用程序管理服务发出blockSignal(false)消息
deactive	向应用程序管理服务发出blockSignal(true)消息
onReverseUserApp	对参与维护的自启动应用开关反转处理，把autostart中的.desktop文件Hidden字段反转并同步Category
onGetListApps	与Model处理应用变化信号结束的信息提供的一个空接口，只用于承接信号处理
onDelUserApp	在autostart文件夹中删去用户不希望继续维护是否自启动的应用并同步Category
onAddUserFile	向autostart中添加用户希望维护是否自启动的应用并同步Category
getCategory	返回应用类型的分类

4.3.3 MimeDBusProxy

名称	功能
MimeDBusProxy	DBusProxy构造函数。
DeleteApp	向应用程序管理服务发送删除App请求。
AddUserApp	向应用程序管理服务发送添加用户App请求。
ListApps	向应用程序管理服务发送展示所有App请求。
Change	向应用程序管理服务发送App变动处理请求。

4.3.4 SelfStartupDetailWidget

名称	功能
SelfStartupDetailWidget	自启动软件条目窗口构造函数。初始化条目窗口中的文字不可编辑、icon大小、条目形状、条目不可移动，初始化存储软件列表的QStandardItemModel，初始化软件条目的布局。
~SelfStartupDetailWidget	自启动软件条目窗口析构函数。
setModel	设置自启动软件条目窗口的当前model。根据当前窗口的分类，设置不同的窗口model（由于本插件目前只有一个分类，因此setModel功能相当于直接调用setCategory功能）。
setCategory	设置自启动软件条目窗口的当前分类。将分类的增、删、改的信号和对应的自启动软件条目窗口的槽函数连接，将分类中的软件放入存储软件列表的QStandardItemModel中，并更新自启动软件条目窗口。
updateListView	更新自启动软件条目窗口。依次读取自启动软件条目窗口的当前model中的每一个软件状态，依照软件状态，更新窗口显示（显示是否自启动、软件名称、软件icon、删除按键）。
getAppIcon	获取软件的icon。从系统中获取软件的icon，并统一调整为32*32大小。
getAppById	通过ID获取APP结构体。遍历分类中的app，返回对应的APP结构体。
appendItemData	向model中新增app信息。从APP结构体中获取app信息，向model中新增app，并更新总app数量。
isDesktopOrBinaryFile	判断文件是否属于桌面或二进制文件。
isValid	判断app是否有效。判断app的ID非空。
reverseItem	向category发出app自启动状态转换的信号。
requestDelUserApp	向category发出删除app的信号。
onListViewClicked	自启动软件条目窗口被点击后的槽函数。从自启动软件条目窗口获取app信息，并向category发出app自启动状态转换的信号。
onDelBtnClicked	自启动软件条目窗口删除按钮被点击后的槽函数。从自启动软件条目窗口获取app信息，并向category发出删除app的信号。
onClearAll	清空model中所有的app信息。
getAppListview	返回model中所有的app信息。
AppsItemChanged	重置model中所有的app信息。依次将app_list中的app信息存入model中，并连接激活、点击信号。
onReverseApp	category返回app自启动状态转换信号的槽函数。更新对应model中app的自启动状态，并更新窗口。
addItem	category返回app新增信号的槽函数。向model中新增对应的app信息，并更新窗口。
removeItem	category返回app删减信号的槽函数。向model中删减对应的app信息，并更新窗口。
showInvalidText	设置自启动软件条目窗口的字体、图标的位置、大小。

4.3.5 SelfStartupPlugin

名称	功能
SelfStartupPlugin	自启动程序插件的构造函数。基于DCC_NAMESPACE::PluginInterface的接口。
name	返回自启动程序插件的名称。
module	自启动程序插件初始化函数。初始化自启动程序插件的一级页面、二级页面和加号按钮。
location	返回自启动程序插件的位置。即，在控制中心插件中的排序。

4.3.6 SelfStartupModule

名称	功能
SelfStartupModule	自启动程序插件一级页面的构造函数。初始化一级页面的名称，描述，图标，work，model。
~SelfStartupModule	自启动程序插件一级页面的解构函数。向m_work、m_model发送删除信号。
work	返回m_work。
model	返回m_model。
active	激活m_work。

4.3.7 SelfStartupDetailModule

名称	功能
SelfStartupDetailModule	自启动程序插件二级页面的构造函数。初始化二级页面的名称，分类，work，model。
page	自启动程序插件二级页面的初始化函数。初始化DetailWidget，并将DetailWidget的app状态修改信号、删除信号与work的槽函数相连接。

4.3.8 Category

名称	功能
Category	Category类构造函数，继承QObject类，每个Category类里面封装相同类型的应用信息
getName	获取当前Category分类的名称
setCategory	设置当前Category的类型名称
getappItem	获取当前Category封装的应用信息
clear	清空当前Category储存的应用信息
addUserItem	把传入应用信息存到Category中并向前端发送更新信号
delUserItem	把目标应用从Category中删除并向前端发送更新信号
reverseUserItem	设置目标应用Hidden字段反转并向前端发送更新信号

5 系统测试情况

5.1前端测试

完成插件安装后，可在 DDE 控制中心中看到名为“自启动程序”的管理选项：

5.2 自启动管理功能测试

点击改图标，可以进入自启动管理界面：

该界面展示了设置所有的自启动项的软件，如果在软件右边出现了蓝色勾，则说明该软件设置了开机自启动。可以通过点击蓝色的勾取消开机自启动的设置，再次点击则可恢复。由此实现了自启动管理的开启、禁用功能。

底部的加号用于添加需要进行自启动管理的软件，点击后跳出选择窗口：

进入软件所安装的文件夹，选择该软件，即可将其添加入自启动管理中。在自启动管理界面中，可以点击软件右侧灰色的叉号，以将该软件剔除出自启动管理的界面。由此实现了自启动管理的添加、删除功能。

6 插件的可扩展性

本次项目的插件完整的覆盖了OSCOMP-proj223的所有需求，但由于只是一个短期开发的项目，因此有构想到了很多可以对插件进行扩展的方面；同时deepin作为开源社区也为开发者提供了良好的扩展接口，我们考虑了以下几点的扩展路径：

6.1 语言扩展

对于translation 板块，我们修改和编译仅仅使用了dde-control-center的zh_CN部分，限于语言广度我们只能提供插件的简体中文和英文模式，对于deepin可以支持的其他语言还有待扩展

6.2 用户体验扩展

由于Linux系统贯彻了"everything is a file"这一思想，因此整个操作系统的磁盘布局是文件化的，用户的应用可以安装到磁盘的任意地方，同时考虑到大部分Linux使用者为具有计算机基础能力的开发者，我们在插件中设计的添加应用按钮是让用户自主找到文件路径并添加。但是对于一般用户，这样的操作可能有些许复杂，所以我们考虑一个提高用户体验的方式：deepin中系统应用和从应用商店获取的用户程序分别分布在了两个文件夹中，如果用户没有自定义路径的话，我们的插件可以在用户请求添加的时候扫描这两个文件夹，提前给用户展示出可能用户希望添加的应用程序可供直接点击添加

6.3 实时性扩展

我们测试了dde-control-center的大部分插件，我们发现几乎所有都没有实现实时扫描磁盘的功能——即如果我们在dde-control-center外部对插件所管理的磁盘进行了修改的话，前端的界面并不会感受到更新而刷新界面。以自启动为例，我们实现了管理插件，但是用户仍然可以在应用菜单栏从控制中心外部添加到自启动中，此时自启动并不会更新页面，需要放回上一级窗口重新启动插件进行扫描。对于这一项扩展，我们考虑了一种方法为新起一个线程不停的扫描autostart文件夹中的.desktop文件并与Category中的比较，如果出现了不一致则发送（Q_Emit）更新窗口的信号，这样可以实现不返回上一级的情况下更新。但该功能只是作为扩展性的一个构想，实际实现的话首先带来的用户体验收益并不是很大，且已经存在插件的情况下应用场景很小，同时开启一个持续扫描的线程对于内存与插件的效率有较大的开销。

6.4 并发性扩展

插件的工作流程包含了修改磁盘与更新内存中的映射同时展示到面板上。对于磁盘的修改会涉及到一定次数的I/O，因此时间开销一定会比内存中信息更新更大的。因此我们思考了可以在此插件的基础上在新起一个进程，用rpc的方式对插件提供服务，服务内容包括对autostart文件夹的增删查改，插件只需要修改内存中的部分并作为rpc客户端向磁盘I/O的服务发送函数调用请求即可

6.5 一致性的扩展

因为插件会同时修改内存与磁盘的信息，并且保证二者相同，此时就会存在一定的一致性问题：

磁盘和内存写入不同步，在其中一个进行的过程中发生了崩溃程序退出，此时是否成功写入成为一个一致性问题。我们的解决方式为先写入磁盘再写入内存，同时在重启插件的时候会重新扫描一次磁盘，这样只要写入磁盘的第一阶段成功之后即使崩溃也可以在重启的时候恢复数据
多进程同时操作：如果有多个控制中心进程同时进行了文件的操作，采取的方式为读磁盘，写磁盘，写内存的操作，这样可以使得在读磁盘的时候如果有同名的应用被添加到里面会被正在写入（包括添加与删除操作）的进程阻塞读取，在写入过程结束之后才会触发读磁盘，然后写内存的时候判断是否存在，如果存在则跳过第三步，如果不存在则再写入磁盘

附录A 插件安装

1 开发环境配置

1.1 配置 Deepin 操作系统

开发环境：Deepin V23Beta版

系统架构：x86

镜像下载链接：https://mirrors.ustc.edu.cn/deepin-cd/releases/23-Beta/

虚拟机平台：WMware Workstation 16Pro

操作系统环境搭建参考博客：https://blog.csdn.net/qq_44133136/article/details/105887560

1.2 配置 Deepin 插件环境

安装依赖包：

sudo apt build-dep .
sudo apt install -y qt5-default
sudo apt-get install dde-control-center-dev

1.3 插件安装测试

安装插件：

sudo sh install.sh

安装成功后，打开控制中心，会看到以下自启动插件图标，即为安装成功：

此时，如果进入/usr/lib/x86_64-linux-gnu/dde-control-center/modules/文件夹，看到编译出的.so文件已经被下载到该文件夹中：

1.4 插件卸载测试

卸载插件：

sudo sh uninstall.sh

重启控制中心，可以看到原本的“自启动管理”图标消失，即为卸载成功。

附录B 开发过程问题记录

1 开发环境配置问题

1.1 Deepin V20 Beta与Deepen V20.9

在开发环境配置过程中，我们遇到了比较大的问题。

我们起初顺延初赛的思路进行开发，在Deepin V20Beta版中进行开发。我们完成相关依赖包的安装后可以顺利地编译我们所写的控制中心自启动插件。但我们发现安装插件后的控制中心只剩我们所编译的自启动插件。（如下图中仅剩测试编译的 Default Applications 和 Self Start-up 插件）

我们推测是因为系统自动配置的控制中心框架与网上的控制中心开源代码版本不同，导致插件安装后框架复写。故我们只需重新编译控制中心的代码重新安装至虚拟机系统中即可完成测试。

然而，在尝试编译控制中心时各种尝试均失败。报错DTK版本不符，未找出解决方法。在Deepen V20.9中亦未成功。

1.2 Deepin V23Beta

在遇到上述问题后，我们加入了Matrix的Deepin开发者社区，在线上与其他开发者讨论我们所遇到的问题。

经过与其他开发者的讨论，我们得知最新的开源版本的控制中心已不再支持 20 版的Deepin系统。

于是我们重新安装最新版本的Deepin V23Beta，成功的将我们所编写的插件植入控制中心中。

2 图标与文字颜色展示问题

我们初步的demo展示出来的界面所有管理的应用程序都是统一显示的默认应用程序的图标，但我们还是希望要和deepin桌面上.desktop文件相同的图标；与此同时，我们发现发现插件中的应用程序名字都是红色，同时希望这里是一个经典的黑色，这两个都是关于item的展示问题。我们关注到了这一段代码：

QIcon icon = getAppIcon(iconName, QSize(32, 32));
act->setIcon(icon);
act->setTextColorRole(DPalette::TextTitle);
act->setIconText(name);

关于icon问题，我们可以对App结构体进行扩展，增加一条icon字段，通过读取带有图标应用程序.desktop文件中的icon字段存到当中，如果没有icon字段的程序设置为“application-default-icon”，并且在展示的时候调用act->setIcon()传入icon字段
关于颜色问题，上述代码中看到了act->setTextColorRole()字段，里面传入了文字颜色类型的变量，在DPalette中定义了如下常量，初始选择的红色文字为TextWarning，我们只需要替换为TextTitle即可

TypeName	颜色类型
ItemBackground	列表项的背景色
TextTitle	标题型文本的颜色
TextTips	提示性文本的颜色
TextWarning	警告类型的文本颜色
TextLively	活跃式文本颜色（不受活动色影响）
LightLively	活跃式按钮（recommend button）背景色中的亮色（不受活跃色影响）
DarkLively	活跃式按钮（recommend button）背景色中的暗色，会从亮色渐变到暗色（不受活跃色影响）
FrameBorder	控件边框颜色
NColorTypes	无颜色类型

3 翻译问题

翻译主要涉及到：插件名的翻译和自启动软件名的翻译。

对于插件名的翻译。我们学习了DDE-NETWORK-CORE仓库的做法，首先我们编写翻译成不同语言的.ts翻译文件，使用CMakelists中的qt5_add_translation指令获得.qm翻译文件，再将翻译的.qm文件install进入${CMAKE_INSTALL_DATAROOTDIR}/dde-control-center/translations（通常是$/usr/share/dde-control-center/translations），在通过loadTranslator载入系统对应语言的翻译文件。

对于自启动软件名的翻译。考虑到部分软件缺失官方翻译名称，无法软件的信息中直接获取，我们目前只采用英文格式。

4 开机启动项处理思路问题

为了实现插件可视化管理软件的开机自启动，了解Deepin系统开机自启动的功能实现是至关重要的。

通过查阅资料与实践，我们了解到Deepin系统包含自启动文件夹~/.config/autostart，该文件夹类似于 Windows 下的启动文件夹，系统开机时会执行该文件夹下的每个 desktop 文件 Exec 参数指向的脚本或可执行文件。

为了确认可行性，小组进行了该方法的验证。首先，通过Deepin系统自带的修改开机自启动设置的方法，修改开机启动项（图中修改终端的自启动项）：

随后检查自启动文件夹~/.config/autostart：

yang@yang-PC:~/.config/autostart$ ls
deepin-terminal.desktop org.deepin.browser.desktop

发现deepin-terminal.desktop文件被添加入了该自启动文件夹中，并且会在开机时自启动。

而取消终端的自启动时，~/.config/autostart中已有的deepin-terminal.desktop文件并不会被移除，而是其中的Hidden的字段会被修改为false，表示取消开机自启动设置。

由此，可以通过在插件中检查所有~/.config/autostart文件夹中.desktop文件的Hidden字段来搜索系统所有的自启动软件；也可以通过添加.desktop文件、修改Hidden字段的方式进行开机自启动设置的修改。

5 rpc远程通信问题

远程过程调用： RPC允许一个程序调用另一个程序在远程机器或进程上执行的过程（函数或方法），就像本地调用一样。这样，开发者可以透明地在分布式系统中调用远程的功能，无需关注底层网络细节。
通信协议： RPC通信需要定义一个协议，该协议规定了消息的格式、编码方式、序列化和反序列化方法等。通过确定的request和response协议格式制定规定了客户端和服务器之间如何进行数据交换。
序列化和反序列化： 在RPC通信中，数据需要在网络上传输，因此需要将数据进行序列化（编码）以便在网络上传输，然后在接收端进行反序列化（解码）以还原数据。序列化和反序列化过程确保数据的正确传输和解释。
数据传输： RPC通信依赖底层的网络传输协议，如TCP或HTTP。客户端和服务器通过网络传输消息，以实现远程过程调用。
错误处理： RPC通信中需要处理各种可能的错误情况，例如网络连接中断、超时、服务不可用等。合理的错误处理可以保证系统的可靠性和鲁棒性。
服务注册与发现： 在dde-application-manager中以字符串命名注册了远程调用函数的服务，dde-control-center中关于对应用的变更可以通过rpc远程调用实现就和
安全性： RPC通信涉及跨网络的数据传输，因此安全性是一个重要考虑因素。加密、认证和授权等机制可以确保通信的安全性。

6 插件描述缺失问题

在加载插件后，我们发现插件缺失了描述信息，与其他的插件格式明显由很大的不同，通过Matrix上交流发现，是插件缺少了setDescription的代码，因此，正确加入描述后，我们获得了以下结果。

附录C 开发计划

第一步（4/9～4/18）

调研Deepin、dde-dock、QT框架等相关内容
设计项目方案
分工

第二步（4/19～5/2）

搭建主体插件类的框架
设计启动项管理窗口的前端展示页面

第三步（5/3～5/13）

开发部件类接口
完善插件类功能

第四步（5/14～5/21）

插件类右键功能开发
完成配置文件

第五步（5/22～5/31）

Debug
撰写文档

（以上DDE-Dock自启动插件开发均在初赛完成，项目地址见末尾）

第六步（6/26～7/8）

调研DDE Control Center框架等相关内容
设计前端界面
分工

第七步（7/9～7/15）

编译教程中的Hello World控制中心插件
设计插件架构

第八步（7/16～7/22）

配置环境，编译V20示例插件
设计后端接口
修改window、operation、category下的文件

第九步（7/23～7/29）

配置环境，编译Default-App与Self Start-up插件
Debug

第十步（7/30～8/10）

修改翻译、文字颜色问题
撰写文档

附录D 参考资料

文档

Qt 插件标准：https://wiki.qt.io/Plugins

deepin V23 dde-control-center文档：dde-control-center: dde-control-center (linuxdeepin.github.io)

dde-control-center控制中心插件开发示例：控制中心插件 - deepin开发者平台

qt-5手册：https://doc.qt.io/qt-5/

deepin 应用自启动说明：https://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.html

博客

关于deepin开机自启动项的讨论：https://bbs.deepin.org/zh/post/169824、https://blog.csdn.net/qq_21137441/article/details/124825726

仓库

dde-control-center仓库：https://github.com/linuxdeepin/dde-control-center.git

其他开发者的插件项目：https://github.com/linuxdeepin/dde-network-core/tree/master

说明：由于控制中心的插件对于外观的统一性具有较高的要求，因此，我们仓库中的include/interface，include/widgets，src/interface，src/widgets，src/frame下的文件均来自dde-control-center源代码仓库，以保证插件接口的一致性和外观的统一性。

DDE v23 正式版移植简要指南

DDE 移植兴趣小组 — Mon, 14 Aug 2023 00:00:00 +0000

编辑的话请把自己的名字加到作者名单里

DDE v23 首个正式版即将随 deepin v23 发布（你阅读到这个文章的时候可能已经发布了）。为了方便各个其它发行版的包维护者可以更方便的移植 DDE 到对应的发行版，这里提供一篇简要的移植指南，用以描述常见的移植问题和解决方案。

下面对项目名称的称呼均以 GitHub 对应的原始仓库名为准。 {.note}

概览

即便本次从版本号字面来看可能并没有较大变动，但事实上，本次相比 beta3 -> rc 而言仍然是存在比较大的变化的。本次中，dde-shell 加载托盘插件的策略做了大幅调整，转变为通过 dde-tray-loader 加载插件，托盘区域的插件也放弃了原有的插件，转而移植并使用了来自原 UOS 20 专业版的托盘插件。此外，为了为后续的应用权限管控做准备，本次也对包括 dde-launchpad、dde-shell 等在内的项目调整了其 DSG 配置文件所使用的应用 ID（DSG_APP_ID），故对于移植到其它发行版的情况，若存在相应的 DConfig OEM 配置则也需进行调整。另外，为了解决一些已知的开源合规问题，我们也将原本位于 dtkcore 中的日志部分分离为了一个单独的组件，名为 dtklog。

由于这些项目的版本间互相影响，我们强烈建议移植人员参照 deepin v23 正式版所使用的包版本进行打包（也务必遵循依赖顺序打包）。下面会对主要的部分进行详细说明。

需要注意的是，由于此文章编写时间早于版本发布时间，故最终版本镜像中使用的版本可能高于下面列出的版本。我们尽可能确保此文章的准确性，但若您需要获取 ISO 镜像中使用的确切软件版本列表，请挂载 ISO 后参阅 LIVE/FILESYSTEM.MANIFEST (也可能是 LIVE/FILESYS0.MAN）路径对应的文件的内容。

主要组件

DTK 与 DTK6

DTK 是 DDE 组件与应用的基础依赖，适用于 RC 的版本参照如下：

package	version
dtkcommon	5.6.32
dtklog	0.0.1
dtkcore	5.6.32
dtkgui	5.6.32
dtkwidget	5.6.32
dtkdeclarative	5.6.32
qt5integration	5.6.32
qt5platform-plugins	5.6.32
dtk6log	0.0.1
dtk6core	6.0.18
dtk6gui	6.0.18
dtk6widget	6.0.18
dtk6declarative	6.0.18
qt6integration	6.0.18
qt6platform-plugins	6.0.18

除新增的 dtklog 外，本次 DTK 版本号以及相对应的平台插件等版本号均已对齐，可直接参照打包。

dtk6 曾对 Qt 6.2, Qt 6.4 和 Qt 6.6 均进行过适配，我们目前的研发与测试主要使用 Qt 6.6 版本，但当前主干也包含了对 Qt 6.7 的支持。如仍发现有 Qt 版本支持问题可在 DDE 移植群（地址见文末）反馈。

目前，使用 dtk6 的正式组件有 dde-application-manager，dde-launchpad 与 dde-shell，需要注意 dde-shell 的托盘组件 dde-tray-loader 仍然需要使用 qt5。

DDE 主要组件

下面仅涉及变化较大或影响较广的组件。其余未涉及的组件可正常参照最新 tag 进行打包与移植。

下面涉及到的组件的版本参照如下：

package	version
deepin-osconfig	2024.08.06
dde-app-services	1.0.25
dde-session	1.2.13
dde-application-manager	1.2.15
dde-tray-loader	0.0.8
dde-shell	0.0.40
dde-launchpad	0.8.4
dde-application-wizard	0.1.10
deepin-wayland-protocols	1.10.0.28
deepin-kwin	5.27.2.206
dde-launcher	被 dde-launchpad 取代，不再使用
dde-dock	被 dde-shell 取代，不再使用

deepin-osconfig

此仓库存放了适用于 deepin 发行版的“OEM”配置。此配置一般 不需要被其它发行版原样移植，但考虑到本次存在针对 DSG 应用 ID 的变化调整，故将其列在此处，仅供移植人员参考对应的修改内容，以便当自己所移植到的目标发行版存在 OEM 配置时做出相应的调整。

dde-application-manager

负责启动和管理 DDE 桌面环境存在的应用程序列表的组件。此组件在 rc 阶段无太大变化（但仍总是建议升级）。

dde-tray-loader

这是一个新增的组件，旨在提供 DDE 的任务栏托盘部分的各个托盘插件。此项目提供了 xembed、SNI 托盘的加载支持，以及旧式 dde-dock 托盘插件的加载支持（因为并非直接兼容的旧式插件，故此项目同时也提供了这些插件）。

此项目需要配合新的 dde-shell 一同使用。

dde-shell

dde-shell 旨在将 DDE 桌面环境插件化与模块化，降低开发难度，使各个组件的替换变得更加容易，并且提供更好的桌面环境集成支持。

相较于 RC 阶段，此组件的变化主要在于任务栏托盘区域的加载逻辑的大幅调整与相关动画的调整，以及 shell 本体功能上的支撑调优。对于托盘区域，请参见新增项目 dde-tray-loader 的描述。另外，RC 阶段内附的一些第三方库（例如 networkmanager-qt）已被移除，故一般无需刻意留意是否存在 vendor libs 的问题。

dde-launchpad

dde-launchpad 相较于 RC 阶段变化并不大，调整大多与缺陷修复以及动画调整有关。需要注意的是，此应用的 DConfig DSG 应用 ID 有变化，故对于移植人员，若原有主动提供针对启动器的 OEM 配置，则需注意修改配置文件放置的对应路径的变化（对应文档也已更新）。

deepin-kwin

启动器与 shell 均依赖窗管提供一些支持（例如窗口组件的状态、位于的工作区以及层级关系的控制等），故请同时确保 deepin-kwin 使用的版本。

需要注意的是，截至编写此文档时，GitHub 中 deepin-kwin 仓库的最新 tag 落后于上述所列的 deepin-kwin 版本，我们正在与相关项目组协商，若您阅读至此时仍无法在 GitHub 获取到对应的版本且 GitHub 所获取的最新版本存在较大问题，则请暂时先从 deepin v23 (beige) 的软件仓库获取对应源码。

dde-session

此项目在 RC 阶段无缺陷修复之外的较大变动。

仍需重申，我们已在 beta3 阶段放弃了对 deepin-kwin wayland 的支持，DDE 后续所有 wayland 相关的支持均由 treeland 提供。

技术预览组件

为全力确保正式版的版本发布，原本涉及的技术预览组件在 RC 至 release 的这个阶段均无较大进展，故不再于此罗列。

获取移植帮助

如果您希望得到移植相关的帮助，请考虑加入我们 DDE 移植小组的在线交流群（下列房间有桥接，任选其一即可），一起展开相关的交流：

Matrix 群：#dde-port:deepin.org
Telegram 群：https://t.me/ddeport

开发一个 KWin 特效插件

justforlxz — Sun, 25 Jun 2023 05:25:55 +0000

KWin 是 KDE 开发的窗口管理器，提供了非常丰富的插件，可以对功能进行大量的定制。

本篇文章是对窗口特效插件的开发介绍。

插件开发

插件定义

KWin 的插件通常可以使用一些宏辅助生成代码，例如使用 KPluginFactory 进行插件的定义，内容是用来生成插件的入口类。

#define EffectPluginFactory_iid "org.kde.kwin.EffectPluginFactory" KWIN_PLUGIN_VERSION_STRING
#define KWIN_PLUGIN_FACTORY_NAME KPLUGINFACTORY_PLUGIN_CLASS_INTERNAL_NAME
#define KWIN_EFFECT_FACTORY_SUPPORTED_ENABLED(className, jsonFile, supported, enabled ) \
 class KWIN_PLUGIN_FACTORY_NAME : public KWin::EffectPluginFactory \
 { \
 Q_OBJECT \
 Q_PLUGIN_METADATA(IID EffectPluginFactory_iid FILE jsonFile) \
 Q_INTERFACES(KPluginFactory) \
 public: \
 explicit KWIN_PLUGIN_FACTORY_NAME() {} \
 ~KWIN_PLUGIN_FACTORY_NAME() {} \
 bool isSupported() const override { \
 supported \
 } \
 bool enabledByDefault() const override { \
 enabled \
 } \
 KWin::Effect *createEffect() const override { \
 return new className(); \
 } \
 };

#define KWIN_EFFECT_FACTORY_ENABLED(className, jsonFile, enabled ) \
 KWIN_EFFECT_FACTORY_SUPPORTED_ENABLED(className, jsonFile, return true;, enabled )

#define KWIN_EFFECT_FACTORY_SUPPORTED(className, jsonFile, supported ) \
 KWIN_EFFECT_FACTORY_SUPPORTED_ENABLED(className, jsonFile, supported, return true; )

#define KWIN_EFFECT_FACTORY(className, jsonFile ) \
 KWIN_EFFECT_FACTORY_SUPPORTED_ENABLED(className, jsonFile, return true;, return true; )

大部分宏只是为了方便结构修改，我们只需要使用 K_PLUGIN_FACTORY 进行插件定义即可。

假设我们开发了一个插件，名字叫 demo，我们只需要在 main.cpp 中使用 KWIN_EFFECT_FACTORY_SUPPORTED 定义

KWIN_EFFECT_FACTORY_SUPPORTED(
 Demo,
 "metadata.json",
 return true;
)

代码展开后是这样的。

class KPLUGINFACTORY_PLUGIN_CLASS_INTERNAL_NAME : public KWin::EffectPluginFactory \
{
 Q_OBJECT
 Q_PLUGIN_METADATA(IID EffectPluginFactory_iid FILE "metadata.json")
 Q_INTERFACES(KPluginFactory)
public: \
 explicit KPLUGINFACTORY_PLUGIN_CLASS_INTERNAL_NAME() {}
 ~KPLUGINFACTORY_PLUGIN_CLASS_INTERNAL_NAME() {}
 bool isSupported() const override {
 return true;
 }
 bool enabledByDefault() const override {
 return true;
 }
 KWin::Effect *createEffect() const override {
 return new Demo();
 }
};

可以看到，其实 KWIN_EFFECT_FACTORY_SUPPORTED 只是为我们生成了工厂函数，辅助生成了一些必要的重载。

metadata.json 文件是用来作为插件的描述信息使用的。

{
 "KPlugin": {
 "Category": "Accessibility",
 "Description": "Allow clip of window content",
 "EnabledByDefault": true,
 "Id": "scissor",
 "License": "GPL",
 "Name": "ScissorWindow",
 "Name[zh_CN]": "窗口圆角"
 },
 "org.kde.kwin.effect": {
 "enabledByDefaultMethod": true
 }
}

特效插件

特效插件是一类可以改变窗口画面的插件，例如我们可以在插件里对窗口进行贴图、变形和裁切，在 DDE 中，就使用特效插件完成了圆角裁切和窗口模糊。

这里使用圆角裁切插件作为例子，首先使用 KWIN_EFFECT_FACTORY_SUPPORTED 宏对插件进行定义， KWIN_EFFECT_FACTORY_SUPPORTED 接受一个 class 作为返回的接口类，它需要继承自 Effect，第二个参数是元信息的 json 文件，第三个参数是返回是否支持，在启用插件时可对当前环境进行判断，例如插件需要使用 OpenGL 对图形进行一些操作，但是当前环境不支持 OpenGL，那么插件就不会启用。

#include "scissorwindow.h"

namespace KWin
{

KWIN_EFFECT_FACTORY_SUPPORTED(ScissorWindow,
 "metadata.json.stripped",
 return ScissorWindow::supported();)

} // namespace KWin

#include "main.moc"

在 Effect 类中有几个不同阶段的方法可以重载。

prePaintScreen
- 设置是否变换窗口或整个屏幕
- 更改将要绘制的屏幕区域
- 做各种内务处理任务，比如初始化你的效果变量
  用于即将到来的绘画过程或更新动画的进度
paintScreen
- 在窗口上画东西（调用后画 effect->paintScreen())
- 绘制多个桌面和/或同一桌面的多个副本
postPaintScreen
- 在动画的情况下安排下一次重绘，不应该在这里画任何东西。
prePaintWindow
- 启用或禁用窗口的绘制（例如启用最小化窗口的绘制）
- 将窗口设置为半透明
- 设置要转换的窗口
- 请求将窗口分成多个部分
paintWindow
- 做各种转换
- 改变窗口的不透明度
- 改变亮度和/或饱和度，如果支持的话
postPaintWindow
- 在动画的情况下为单个窗口安排下一次重绘
  不应该在这里画任何东西。
paintEffectFrame
- 在绘制 EffectFrame 之前直接调用此方法。
- 如果需要绑定shader或者执行，可以实现这个方法帧渲染前的其他操作。
drawWindow
- 可以调用以绘制一个窗口的多个副本（例如缩略图）。
- 可以在这里改变窗口的不透明度/亮度/等，但不能做任何转换。
- 在基于 OpenGL 的合成中，框架确保上下文是最新的

在方法名称中可以看出，在场景及窗口绘制的过程中，分别可以在实际绘制的前后分别执行一些动作，圆角插件就是在 drawWindow 函数中，使用 OpenGL 对窗口使用着色器进行窗口裁切，并绘制到屏幕上。

void ScissorWindow::drawWindow(EffectWindow *w, int mask, const QRegion& region, WindowPaintData &data) {
 if (w->isDesktop() || isMaximized(w)) {
 return effects->drawWindow(w, mask, region, data);
 }

 QPointF cornerRadius;
 const QVariant valueRadius = w->data(WindowRadiusRole);
 if (valueRadius.isValid()) {
 cornerRadius = w->data(WindowRadiusRole).toPointF();
 const qreal xMin{ std::min(cornerRadius.x(), w->width() / 2.0) };
 const qreal yMin{ std::min(cornerRadius.y(), w->height() / 2.0) };
 const qreal minRadius{ std::min(xMin, yMin) };
 cornerRadius = QPointF(minRadius, minRadius);
 }

 if (cornerRadius.x() < 2 && cornerRadius.y() < 2) {
 return effects->drawWindow(w, mask, region, data);
 }

 const QString& key = QString("%1+%2").arg(cornerRadius.toPoint().x()).arg(cornerRadius.toPoint().y()
 );
 if (!m_texMaskMap.count(key)) {
QImage img(QSize(radius.x() * 2, radius.y() * 2), QImage::Format_RGBA8888);
 img.fill(QColor(0, 0, 0, 0));
 QPainter painter(&img);
 painter.setPen(Qt::NoPen);
 painter.setBrush(QColor(255, 255, 255, 255));
 painter.setRenderHint(QPainter::Antialiasing);
 painter.drawEllipse(0, 0, radius.x() * 2, radius.y() * 2);
 painter.end();

 m_texMaskMap[key] = new GLTexture(img.copy(0, 0, radius.x(), radius.y()));
 m_texMaskMap[key]->setFilter(GL_LINEAR);
 m_texMaskMap[key]->setWrapMode(GL_CLAMP_TO_EDGE);
 }

 ShaderManager::instance()->pushShader(m_filletOptimizeShader);
 m_filletOptimizeShader->setUniform("typ1", 1);
 m_filletOptimizeShader->setUniform("sampler", 0);
 m_filletOptimizeShader->setUniform("msk1", 1);
 m_filletOptimizeShader->setUniform("k", QVector2D(w->width() / cornerRadius.x(), w->height() / cornerRadius.y()));
 if (w->hasDecoration()) {
 m_filletOptimizeShader->setUniform("typ2", 0);
 } else {
 m_filletOptimizeShader->setUniform("typ2", 1);
 }
 auto old_shader = data.shader;
 data.shader = m_filletOptimizeShader;

 glActiveTexture(GL_TEXTURE1);
 m_texMaskMap[key]->bind();
 glActiveTexture(GL_TEXTURE0);
 effects->drawWindow(w, mask, region, data);
 ShaderManager::instance()->popShader();
 data.shader = old_shader;
 glActiveTexture(GL_TEXTURE1);
 m_texMaskMap[key]->unbind();
 glActiveTexture(GL_TEXTURE0);
 return;
}

如果窗口是桌面类型，或者已经最大化了，则无需处理，直接返回 Effect 原本的处理函数。

之后尝试从窗口属性中取出圆角大小的值，如果没有设置圆角大小，或者值小于2，则无需处理。

尝试查询缓存，在这里为窗口的四个角构建一份遮罩对象并缓存，使用 OpenGL 将遮罩和着色器进行关联，激活两个材质分别绘制窗口内容和四个角的遮罩，在着色器中完成窗口圆角的半透明效果。

限于篇幅，本文不展开介绍如何实现圆角插件的全部实现过程，仅挑选关键步骤。

安装

将动态库复制到 /usr/share/kwin/effects/plugins ，并使用 DBus 激活插件。

qdbus --literal org.kde.KWin /Effects org.kde.kwin.Effects.loadEffect scissor

V23 Beta DDE Wayland解读

deepin 社区官方博客 — Thu, 01 Jun 2023 05:37:41 +0000

在 V23 beta 版本中，DDE 试验性的开启了 Wayland 的支持，允许用户在 Wayland 协议下的桌面工作环境启动。本篇文章会向大家介绍一下 Wayland 是什么，我们尝试做了什么改变，以及 DDE Wayland 未来会支持哪些新特性。（注：单独提出 Wayland，通常和 Wayland 合成器、Wayland 服务器、显示服务器被视为同一个内容；X Window System 和 X11 也被视为同一个内容。）

什么是 Wayland？

Wayland 是一个通信协议，规定了显示服务器与客户端之间的通信方式，而使用这个协议的显示服务器称为 Wayland Compositor。Wayland 只专注于图形，并希望使用其他库与输入硬件进行通信，以降低自身的复杂度。Wayland 最大的好处也是大家都推崇的原因，那就是 Wayland 在设计上会考虑安全，例如默认不允许窗口获取其他窗口的数据，合成器和窗口管理器的合并也降低了对系统资源的消耗。

Wayland 与 X Window System 有什么不同？

Wayland 与 X Window System 的最大不同在于，Wayland 与 X Window System 的最大不同在于，它的窗口管理器和 Wayland Server 在同一个进程，并且客户端能够通过 EGL 以及一些 Wayland 特定的 EGL 扩充组件直接在显示内存中绘制自己的缓冲区。窗口管理器简化成显示管理服务，专门负责绘制那些屏幕上的程序。这比 X Window System 中的窗口管理器要更简单、高效。

Wayland 协议有哪些组成？

1.协议概述

Wayland 协议被描述为异步面向对象协议。协议是异步的，这意味着不必等待回复或者响应 ACK，避免了往返时间并提高性能。协议封装为面向对象的设计，则是面向对象的设计方式，能很好的对服务器上不同窗口数据及接口进行封装。

Wayland 合成器可以定义和公开自己的附加接口，被称为扩展协议，不同的 Wayland 会提供功能完全不同，甚至功能相反的协议，这带来了很大灵活性，但使用客户端时需要自行判断。

2.协议架构

Wayland 协议是一种“客户端 —— 服务器”模型，客户端是请求在屏幕上显示画面的图形应用程序，服务器是控制应用程序显示在屏幕上的管理程序。Wayland 参考实现被设计成两层协议，既：

下层协议：处理客户端和服务器之间的进程间通信，以及在内部的数据封装处理。
上层协议：处理客户端和服务器交换的数据，以实现窗口系统的基本功能，这一层被实现为异步面向对象协议。下层协议是使用 C 语言开发的，而上层协议是根据 XML 格式的协议描述文件自动生成，每当 XML 协议的描述发生变化时，就可以重新生成该协议的源代码，这使得协议非常灵活、可扩展性好且防止出错。

如下 Wayland 工作原理图：

以下对应图中所标编号作说明：

①Linux 内核中的 evdev 模块接收事件并将它们发送到 Wayland 合成器。

②Wayland 合成器查看场景图并确定哪个窗口应接收事件。场景图对应于屏幕上显示的内容，Wayland 合成器显示对应用事件的场景图中元素的转换。因此，Wayland 合成器可以反向变换以找到正确的窗口，并将屏幕上的坐标转换为窗口中的坐标。

③当客户端收到事件时，Wayland 的客户端只需通过 EGL 渲染并向合成器发送请求以通知更新的范围即可。

④Wayland 合成器从客户端收集更改请求并重新配置屏幕。然后，合成器直接发出 ioctl 让 KMS 重绘屏幕。

当了解了 Wayland 相关基本介绍之后，基于它我们在 DDE 上将会作哪些适配功过呢？将从以下几个方面说一下我们在 Wayland 技术预览版里面所做的适配工作。

DDE 适配 Wayland 都做了哪些工作

DDE 原本设计为在 X11 协议下工作，很多组件直接或间接依赖 X11 的接口，多数组件依赖的功能并没有在 XWayland 中提供，所以就需要进行一些修改。

首先在 Qt 插件中实现和 Wayland 特定性相关的功能，Qt 提供了一个 Wayland Shell Integration 的插件，允许我们在这里调用 DDE Wayland 合成器提供的扩展协议。

Qt 已提供核心协议的适配，所以 DDE 只需要在现有框架下实现扩展协议即可。

目前 DDE 提供的扩展协议有以下几个方面：

设置圆角窗口
请求获取窗口数据（截图权限）
划分工作区可用区域 DTK 程序可以通过设置窗口的属性，或者使用 DTK 提供的平台接口，即可调用扩展的 Wayland 协议，非 DTK 程序则需要手动使用扩展协议的 XML 文件进行代码生成调用。

DDE Wayland 未来会支持什么特性？

1.HDR 支持

高动态范围（HDR）是比平时更高的动态范围。HDR 的内容过于深入，在这里只简单的进行说明。

HDR 可以保存更多的内容信息，在支持 HDR 的屏幕上观看 HDR 的内容，可以获得更好的体验，DDE 目前正在准备支持 HDR 内容的输出，这会让 DDE 拥有更好的显示效果。

2.成体系的窗口动画

在 X11 下，由于窗口管理和画面合成管理是两个进程，并且在启动速度上存在差异，所以只能采用一些“巧妙”的设计来规避视觉错误。

但是在 Wayland 下，窗口管理器和窗口合成器被合并成一个进程，那么启动后就可以立即使用动画效果，例如可以设计视觉效果更好的登录动画。

目前 DDE 的窗口动画支持并不多，且大部分是单调的线性动画，有些情况还需要客户端自己实现虚假动画，例如任务栏发生位置变化时，桌面的图标会进行计算，并自行改变大小，这引入了非必要的依赖。如果使用窗口动画，桌面并不需要关心任何外部因素，只需要设置自己在可用工作区域最大化，当任务栏发生位置改变时，合成器会自动调整桌面的大小，并产生相应的窗口动画。

未来 DDE 会使用更多窗口动画来减少组件之间的依赖，以及实现更多更好的视觉效果。

最后总结

阅读至此，是不是对 Wayland 的概念及工作原理更加清晰啦？如果您有什么疑问也欢迎与我们互动探讨 Wayland。

坦白说，DDE 的 Wayland 支持还处于初步阶段（技术预览版，请谨慎使用），未来我们会使用更多合成器提供的功能，来为桌面环境降低开发难度，提升性能。提供更好的体验。

DDE-Dock 自启动管理插件项目文档

dde 自启动管理插件开发小组博客 — Tue, 30 May 2023 06:00:00 +0000

队员：复旦大学朱元依、沈扬、朱俊杰
指导老师：张亮、陈辰
企业导师：王子冲

本项目为2023年操作系统大赛企业赛道赛题。

项目链接：DDE 自启动管理插件 github仓库

一、目标描述

我们小组的选题为proj223-control-center-startup-management-plugin

DDE 深度桌面环境的控制中心提供了插件功能，以便第三方开发者可以扩展其功能并额外的功能组件添加到控制中心之中。我们将在本项目中为 DDE 桌面环境的控制中心编写一个自启动管理插件。

二、比赛题目分析和相关资料调研

为了明确题目设置的原因与需求，我们请教了了企业导师，得知：目前用户对自启动权限的管理目前只能通过 dde-launcher （启动器/“开始菜单”）的右键菜单进行管理；考虑到此功能本身也并不复杂，所以设置了此课题，旨在解决这样的问题。

而对于此开发任务的具体实施，主要需要对dde-dock插件运行的原理和deepin开机自启动的设置方式进行调研，以便进行开发。调研的具体内容包括：

了解了Qt 插件标准（Qt 插件标准）

阅读整理了dde-dock官方仓库中的插件工作原理（插件工作原理）

学习其他开发者的插件项目（CMDU_DDE_DOCK）

阅读整理了各个论坛中关于deepin开机自启动项的讨论（169824、124825726）

三、系统框架设计

1、项目整体结构设计

符合dde-dock提供的接口与插件开发规范，本项目将分为插件类（SelfStartPlugin）、部件类（MainWidget）和自启动管理窗口（AppletWidget）分别进行功能的实现。其中，项目的结构和各对象所包含的数据结构与方法如下图所示：

2、类功能说明

插件类SelfStartPlugin负责实现插件与dde-dock交互所必须的接口；部件类MainWidget负责在dde-dock中展示该插件的图标；自启动管理窗口AppletWidget负责实现核心功能：读取Deepin系统的开机自启动项、同时对各个软件的开机自启动进行管理（包括添加、删除、启用、禁用）。

3、实现描述

（1）插件类

在插件类中，主要实现了dde-dock中 PluginItemInterface相关的接口，便于系统加载并实现插件的功能。接口包括以下内容：

名称	功能
SelfStarupPlugin	类的初始化函数
pluginName	返回插件名称，用于在 dde-dock 内部管理插件时使用
init	插件初始化入口函数，参数 proxyInter 可认为是主程序的进程
pluginDisplayName	返回插件名称，用于在界面上显示
itemWidget	返回插件主控件，用于显示在 dde-dock 面板上
itemPopupApplet	返回鼠标左键点击插件主控件后弹出的控件
flags	用于返回插件的属性，例如插件显示的位置，插件占几列，插件是否支持拖动等
pluginIsAllowDisable	返回插件是否允许被禁用（默认不允许被禁用）
pluginIsDisable	返回插件当前是否处于被禁用状态
pluginStateSwitched	当插件的禁用状态被用户改变时此接口被调用
itemContextMenu	返回鼠标左键点击插件主控件后要执行的命令数据
invokedMenuItem	返回鼠标右键点击插件主控件后要显示的菜单数据

（2）部件类

名称	功能
MainWidget	`MainWidget`部件的初始化函数，设置`dde-dock`图标的基础样式与文字内容
~MainWidget	`MainWidget`部件的析构函数
sizeHint	设置图标大小的函数

插件图标

最左侧的SELF_STARTUP图标为该插件图标。

（3）自启动管理窗口

名称	功能
AppletWidget	`AppletWidget`的初始化函数，负责绘制与用户交互的开机自启动项展示表格与修改设置选项
~AppletWidget	`AppletWidget`部件的析构函数
searchAll	搜索所有可设置开机自启动的软件
update	更新被自启动的软件
readfiles	工具函数，用于读取文件中的内容
disable	禁用开机自启动设置的后端接口
enable	启用开机自启动设置的后端接口
add	添加开机自启动设置的后端接口
delete	删除开机自启动设置的后端接口
getFileName	通过绝对路径找到文件的名字
getAllFiles	递归获取到某目录中所有文件
globalSearch	在所有文件中找到.desktop类型文件
Manual	寻找拟添加软件的函数，给用户在系统中寻找想要添加自启动项的软件
showApps	Debug工具，在Debug信息中打印软件名称
showPaths	Debug工具，在Debug信息中打印路径名称
onButtonClicked	自启动管理窗口启用/禁用按钮的处理函数
addButtonClicked	自启动管理窗口添加按钮的处理函数
delButtonClicked	自启动管理窗口删除按钮的处理函数

自启动管理窗口的前端页面

在AppletWidget的构造函数中，我们实现了便于用户查看系统开机自启动设置信息列表、并便于管理的前端展示页面：

开机自启动管理的后端接口

该部件中，主要设置了四个函数接口实现与操作系统的交互，分别是searchAll、update、disable、enable

首先要在MainWidget启动的时候在/home中读到用户名username

searchAll()

在opt/apps中找到所有用户下载程序的文件夹，读入文件夹名称subdir，再到opts/appp/subdir/entries/application中找到.desktop启动文件，解析文件内容，读入name字段并把name - path存到MainWidge类中，并且返回所有找到的app名称

update()

根据启动时读到的username在/data/home/username/.config/autostart里面找到里面所有的.desktop文件，分别读取并获取状态Hidden是否为false，把所有Hidden字段为False的插件（被设置成了开机自启动）在MainWidget的selfSetUp成员中设置为pair<name, true>

disable()

功能设计为禁用自启动。通过name_path中对name的索引找到路径path，对设置为自启动的应用path会在/data/home/username/.config/autostart/*.desktop中。读取该.desktop文件修改Hidden字段为True即可

enable()

功能设计为启用自启动。对于之前添加过的应用，name_path中得到的路径是在/data/home/username/.config/autostart中，此时与disable()过程相同，把Hidden字段设置成false即可；对于之前没有添加过的应用，name_path中的路径会在opts/appp/subdir/entries/application/appname/entries/application/*.desktop中，并且该文件是只读的。需要读取该文件并写入到/data/home/username/.config/autostart/*.desktop中，并且在文件的第一个分区里面写入一行"Hidden=false"

Add()

用户点击后打开文件资源管理器对话框，从中选择希望添加的可执行文件并返回文件路径。如果该文件是一个.desktop类型文件则添加到autostart中，如果不是则会在autostart中创建一个新的.desktop文件，并且把Exec=行设置为该可执行文件的路径

Delete()

从管理窗口中删除某应用的管理。传入参数是应用名称，找到该应用的.desktop文件路径并从autostart中删除，并且在数据结构name_path和selfSetUp中删去该部分信息

四、开发计划

第一步（4/9～4/18）

调研Deepin、dde-dock、QT框架等相关内容
设计项目方案
分工

第二步（4/19～5/2）

搭建主体插件类的框架
设计启动项管理窗口的前端展示页面

第三步（5/3～5/13）

开发部件类接口
完善插件类功能

第四步（5/14～5/21）

插件类右键功能开发
完成配置文件

第五步（5/22～5/31）

Debug
撰写文档

五、比赛过程中的重要进展

日期	进展
4/17	完成开发环境配置
4/27	完成插件框架设计
5/3	完成自启动管理界面的实现
5/8	完成自启动管理接口实现的讨论
5/12	完成自启动操作项的接口设计与实现
5/21	完成配置文件，并通过cmake编译
5/22	完成图标的Debug，前端界面展示正常
5/29	完成自启动操作接口Debug

六、系统测试情况

1、前端测试

在项目总路径下运行install.sh脚本，可完成插件的编译与安装：

sh install.sh

该脚本使用cmake编译代码，并安装到dde-dock插件文件夹中。运行后，可以正常展示自启动管理页面。点击加号后，用户可以在弹窗中选择想要添加自启动项的软件。

右键功能展示正常：

2、自启动管理功能测试

以浏览器为例。根据自启动管理窗口的设置，我们尝试添加并启用浏览器的自启动项。关机重启后，浏览器完成自启动。同理，删除、禁用功能均通过测试。

七、遇到的主要问题和解决方法

1、开发环境配置

（1）、配置 Deepin 操作系统

开发环境：Deepin 20Beta版

系统架构：x86

镜像下载链接：Deepin 操作系统下载链接

虚拟机平台：WMware Workstation 16Pro

操作系统环境搭建参考博客：环境搭建博客

（2）、配置 Deepin 插件开发环境

安装基本开发环境：

安装包 build-essential、git、g++、cmake、dde、dtk

sudo apt install build-essential git g++ cmake
sudo apt install dde-dock-dev libdtkwidget-dev

安装 QT 开发环境：

安装 qt5-default、qt5-doc、qtcreator

sudo apt install qt5-default qt5-doc qtcreator

依照上述方法，可在虚拟机中运行qtcreator，并在qtcreator中对插件进行测试

（3）、插件安装测试

为了测试所配置的虚拟机环境可用于 DDE 插件的开发，在环境配置中，本小组选取了Github仓库中的插件dde-sys-monitor-plugin（项目地址：dde-sys-monitor-plugin插件仓库）进行试运行。

根据上述方法配置插件开发环境后，可按照dde-sys-monitor-plugin中的提示信息顺利运行该插件。这表明开发环境配置已完成。

（4）环境配置中遇到的问题

安装sudo apt install libdtkwidget-dev libdtkgui-dev libdtkcore-dev出错

正试图覆盖 /usr/lib/x86_64-linux-gnu/qt5/mkspecs/features/dtk_install_dconfig.prf，它同时被包含于软件包 libdtkcommon-dev 5.5.23-1

在处理时有错误发生：

/var/cache/apt/archives/libdtkcore-dev_5.6.4-1+rb1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

解决方法：

使用sudo apttitude install libdtkwidget-dev libdtkgui-dev libdtkcore-dev 选择第二种解决方式（先卸载nY再重新安装sudo apt install libdtkwidget-dev libdtkgui-dev libdtkcore-dev）

2、开机启动项处理思路

为了实现插件可视化管理软件的开机自启动，了解Deepin系统开机自启动的功能实现是至关重要的。

为了确认可行性，小组进行了该方法的验证。首先，通过Deepin系统自带的修改开机自启动设置的方法，修改开机启动项（图中修改终端的自启动项）：

随后检查自启动文件夹~/.config/autostart：

yang@yang-PC:~/.config/autostart$ ls
deepin-terminal.desktop org.deepin.browser.desktop

发现deepin-terminal.desktop文件被添加入了该自启动文件夹中，并且会在开机时自启动。

3、与 deepin 接口设计

（1）、关于开机自启动项

在查找deepin如何实现开机自启动时，看到了在deepin文件夹中有多个名为autostart的文件夹，其中有一部分包含了系统文件（例如终端、输入法等），但是在我们通过“开始”菜单修改其是否自启动性质时发现并为出现变化，并且我们自行在“应用商店”里面下载的软件并没有在设置为开机自启动后进入到该文件夹。经过在网络上搜索了关于deepin开发的一些讨论资料以及学习了一些关于启动文件.desktop文件功能并通过vscode对是否开机自启动设置后的文件进行比较后，找到了文件路径位于/data/home/username/.config/autostart中，并且在文件中有Hidden字段使得不用每次取消自启动是都要删除文件并且下次设置又重新加入

（2）、关于查找应用程序

一开始的想法是在系统目录下整体查找，找到系统中所有的.desktop文件，但显然这样过于繁琐且效率低下。后来在通过打开每个引用的.desktop文件后发现exec项均在/opt/apps中，打开该文件夹可以发现里面有所有用户下载的应用程序及其依赖等文件的文件夹，并在打开每个文件夹后可以找到启动文件均在entries/application中，并且可能有多个.desktop文件，所以把自启动的工作变为了对启动器文件用文本方式打开后的解析与修改

（3）、关于函数接口设计

对QT库中的数据类型和class的使用不太熟悉，需要根据官方文档对提供的api和C++模式的代码进行替换。但熟悉使用之后理解到了QT数据类型的多样性以及提供的方法会更加完备，在做开发时避免了很多自己重写方法的复杂流程。

4、cmake中遇到的问题

（1）、cmake 出现 dbus、core 找不到

解决方法：find_package()的REQUIRED后面新增找不到的对应的包

（2）、cmake 出现 FOUND=FALSE

 /usr/lib/x86_64-linux-gnu/cmake/DtkWidget/DtkWidgetConfig.cmake
 but it set DtkWidget_FOUND to FALSE so package "DtkWidget" is considered to
 be NOT FOUND.

解决方法：使用.pro文件设置cmake需要的相关参数。

八、分工和协作

朱元依：插件类框架开发、部件类前端开发

沈扬：自启动管理功能逻辑设计、插件类右键功能开发

朱俊杰：自启动管理窗口后端接口开发（添加、删除、启用、禁用）

九、提交仓库目录和文件描述

.
├── CMakeLists.txt
├── README.md
├── aboutdialog.cpp #关于窗口的实现文件
├── aboutdialog.h #关于窗口的头文件
├── aboutdialog.ui #关于窗口的UI文件
├── appletwidget.cpp #自启动管理窗口的实现文件
├── appletwidget.h #自启动管理窗口的头文件
├── images #图片
│ ├── QT_IDE.png
│ ├── QT_前端.png
│ ├── deepin自启动修改.png
│ ├── 类图.jpg
│ ├── 右键.png
│ ├── 图标.png
│ ├── 结果.png
│ ├── 中期类图.jpg
│ ├── 中期测试.png
│ └── 前端界面.png
├── install.sh #插件安装脚本
├── main_aboutdialog_test.cpp #关于窗口的测试文件
├── main_test.cpp #测试文件
├── mainwidget.cpp #插件类的实现文件
├── mainwidget.h #插件类的头文件
├── self_startup.json #插件的元数据文件，指明了当前插件所使用的 dde-dock 的接口版本
├── self_startup.pro #辅助 cmake 的配置文件
├── self_startup.qrc #用于展示插件图片
├── selfstartupplugin.cpp #部件类的实现文件
├── selfstartupplugin.h #部件类的头文件
├── uninstall.sh #插件卸载脚本
├── 初赛报告.md
└── 过程文档.md

十、比赛收获

借由为deepin的dde-dock编写插件的机会，我们小组了解了deepin系统相关的接口、dde-dock插件加载原理、开发逻辑等等操作系统相关的知识；同时我们在合作开发的过程中熟悉了软件工程的开发规范。小组同学在比赛中均受益匪浅。

十一、与企业导师的沟通情况

我们已于企业导师（王子冲）通过电子邮件进行联系。王导师向我们推荐了 deepin 开源社区各种公开渠道（如实时聊天渠道 Matrix、开发者社区讨论板等），鼓励我们在开发过程中将所遇到的问题在社区研发话题板块中进行公开探索。

此外，王导师还耐心的向我们介绍了该课题的设置原因，这对与我们在项目设计的过程中了解用户需求起到了很大的作用。

deepin-for-arm64支持 - Zeno-sole

zeno — Mon, 29 May 2023 03:15:00 +0000

【摘要】arm64架构支持 v23仓库已经支持arm64和amd64架构软件包，arm64架构的基础环境已经具备，现在就差镜像制作工具的支持了，镜像构建工具的目标是构建出标准pc镜像。为此我借来一台紫光飞腾D2000机器进行arm64的适配工作，这台机器有相对标准的UEFI固件，目前已经支持UEFI安装，阅读全文

DDE v23 RC 移植简要指南

DDE 移植兴趣小组 — Sun, 14 May 2023 00:00:00 +0000

编辑的话请把自己的名字加到作者名单里

DDE v23 RC 即将随 deepin v23 RC 发布（你阅读到这个文章的时候可能已经发布了）。为了方便各个其它发行版的包维护者可以更方便的移植 DDE 到对应的发行版，这里提供一篇简要的移植指南，用以描述常见的移植问题和解决方案。

下面对项目名称的称呼均以 GitHub 对应的原始仓库名为准。 {.note}

概览

相比 beta2 -> beta3 而言，原本处于技术预览状态的 dde-shell 项目现已开始逐步取代部分旧的 DDE 组件。DDE 此次 beta3 -> RC 的更新中，dde-shell 取代了 dde-dock 项目，dde-launchpad 也开始转为使用 dde-shell 的对应插件版本。同时，由于对 Qt6 与 DTK6 使用的增加，我们也对 DTK 进行了大量的问题修复，这些修复也被对应的组件（dde-launchpad 与 dde-shell）依赖。

由于这些项目的版本间互相影响，我们建议移植人员参照 deepin v23 RC 所使用的包版本进行打包，下面会对主要的部分进行详细说明。

需要注意的是，由于此文章编写时间早于版本发布时间，故最终版本镜像中使用的版本可能高于下面列出的版本。我们尽可能确保此文章的准确性，但若您需要获取 ISO 镜像中使用的确切软件版本列表，请挂载 ISO 后参阅 LIVE/FILESYS0.MAN 路径对应的文件的内容。

主要组件

DTK 与 DTK6

DTK 是 DDE 组件与应用的基础依赖，适用于 RC 的版本参照如下：

package	version
dtkcommon	5.6.29
dtkcore	5.6.29
dtkgui	5.6.29
dtkwidget	5.6.29
dtkdeclarative	5.6.29
qt5integration	5.6.29
qt5platform-plugins	5.6.29
dtk6core	6.0.16
dtk6gui	6.0.16
dtk6widget	6.0.16
dtk6declarative	6.0.16
qt6integration	6.0.16
qt6platform-plugins	6.0.16

本次 DTK 版本号以及相对应的平台插件等版本号均已对齐，可直接参照打包。

dtk6 曾对 Qt 6.2, Qt 6.4 和 Qt 6.6 均进行过适配，我们目前的研发与测试主要使用 Qt 6.6 版本。对于 Qt 6.7 我们暂未进行主动支持，对于 Qt 6.7 的相关处理请先参照 Arch Linux 目前使用的 qt-6.7.patch。

目前，使用 dtk6 的正式组件有 dde-application-manager，dde-launchpad 与 dde-shell，技术预览组件有 treeland。

DDE 主要组件

下面仅涉及变化较大或影响较广的组件。其余未涉及的组件可正常参照最新 tag 进行打包与移植。

下面涉及到的组件的版本参照如下：

package	version
dde-session	1.2.9
dde-application-manager	1.2.12
dde-shell	0.0.23
dde-launchpad	0.6.12
dde-application-wizard	0.1.5
dde-dock	被 dde-shell 取代，不再使用

dde-application-manager

本次此组件并不存在如 beta2 -> beta3 阶段时的巨大变化，但由于此组件仍为诸多组件的核心依赖，并且此组件也因其它组件需要而增加了一些新的接口，故建议总是使用最新版本。

dde-shell

dde-shell 旨在将 DDE 桌面环境插件化与模块化，降低开发难度，使各个组件的替换变得更加容易，并且提供更好的桌面环境集成支持。RC 阶段，dde-shell 已经可以满足原计划的部分目标。现 DDE 环境下，dde-shell 已取代 dde-dock 来负责管理整个 dock 区域，并且 dde-launchpad 也提供了（且默认使用）对应的 dde-shell 插件，用以展示启动器相关的界面。

尽管 dde-shell 也包含了一份通知中心插件，但这个插件并不会在 RC 中被启用。

出于初期快速开发目的，dde-shell 本身内附了诸多其它项目的托盘插件代码以及一些第三方库，这部分的代码会在后续版本迭代中逐渐被调整或移除。对于这些代码，可在移植过程中先行酌情调整或移除。项目内附的 networkmanager-qt 依赖也会在后续移除，转而使用系统版本。由于 RC 版本不会涵盖此变更，若有需要，请参见 linuxdeepin/dde-shell#286。

dde-launchpad

RC 版本中，dde-launchpad 不再支持 Qt 5 构建，也不再直接支持以独立进程的形式被最终用户使用（事实上仍然支持，但仅供开发调试场景下使用）而仅支持以 dde-shell 插件的形式被最终用户使用。因而，打包 dde-launchpad 现需要先打包 dde-shell，并确保用户最终使用的是 dde-shell。

dde-session

在之前的版本中，dde-session 提供的相关 systemd 服务依赖关系会导致进入 KDE 环境时也会拉起 DDE 相关的服务，最终由于拉起失败导致 KDE 环境也无法进入。在 RC 版本的 dde-session 中，此问题应当已被解决。

另外重申，我们已在 beta3 阶段放弃了对 deepin-kwin wayland 的支持，DDE 后续所有 wayland 相关的支持均由 treeland 提供。

技术预览组件

技术预览阶段的组件均可酌情决定是否打包。需要注意的是，这些组件并不一定在 RC 阶段存在改善。

treeland / ddm

treeland 目前是技术预览阶段的项目，兼顾 Wayland 窗口合成器和显示管理功能。treeland 除需要 dtk6declarative 外，还依赖新项目包括 waylib 和 qwlroots。需要使用 Qt 版本 >= 6.6.0， wlroots 版本 >= 0.17.0 编译 qwlroots/waylib。

ddm 的仓库也在 RC 阶段进行了拆分，现在 ddm 与 treeland 已是分别独立的两个仓库进行维护了。

deepin-im

treeland 目前是技术预览阶段的项目，提供了输入法的抽象层。目前，deepin-im 仅期望在 treeland 环境下使用。它会设置 QT_IM_MODULE 等环境变量的值来影响实际使用的输入法模块。

RC 版本中，并未涉及对 deepin-im 组件的改善。

获取移植帮助

如果您希望得到移植相关的帮助，请考虑加入我们 DDE 移植小组的在线交流群（下列房间有桥接，任选其一即可），一起展开相关的交流：

Matrix 群：#dde-port:deepin.org
Telegram 群：https://t.me/ddeport

Kitty configuration for macOS

justforlxz — Mon, 17 Apr 2023 08:39:51 +0000

I’ve been using Kitty for a couple of days. I use it because there is a plugin for nvim that can seamlessly switch focus with kitty, so I don’t need to repeat the settings, I like it very much.

After a period of use. I have completed part of the configuration, and now I want to share it.

I use different folders for related functions. Such as themes, tabs, windows, and shortcuts.

# lxz @ lxzMacBook-Pro in ~/.dot/kitty/.config/kitty on git:master o [16:38:58]
$ tree
.
├── kitty.conf
├── kitty.d
│   ├── init
│   │   └── init.conf
│   ├── keybind
│   │   ├── init.conf
│   │   ├── nvim.conf
│   │   ├── tab.conf
│   │   └── window.conf
│   ├── session
│   │   └── init.conf
│   └── theme
│   ├── background.conf
│   ├── color.conf
│   ├── font.conf
│   ├── tabbar.conf
│   └── window.conf
└── session.conf

6 directories, 13 files

Some screenshot

session (look at the lower left corner)

multi splits

Base settings

In kitty.conf, I just set to load configuration files in other directories.

globinclude kitty.d/**/*.conf

I won’t show the configuration after splitting, just give a hint according to the function.

Init

In init.conf, I set some default variables.

term xterm-256color
shell_integration enabled
allow_hyperlinks yes
editor nvim

Theme settings

Tabs settings

In tabs settings, I like powerline style.

tab_bar_style powerline

Windows settings

window_border_width 0.5pt

window_resize_step_cells 2
window_resize_step_lines 2

initial_window_width 640
initial_window_height 400

draw_minimal_borders yes

inactive_text_alpha 0.7

hide_window_decorations no

macos_titlebar_color background
macos_thicken_font 0.75

active_border_color none

# default layout is vertical splits only
enabled_layouts splits

enable_audio_bell no

Fonts settings

font_family FiraCode Nerd Font Mono Retina
font_size 16.0

Color settings

# Dark One Nuanced by ariasuni, https://store.kde.org/p/1225908
# Imported from KDE .colorscheme format by thematdev, https://thematdev.org
# For migrating your schemes from Konsole format see
# https://git.thematdev.org/thematdev/konsole-scheme-migration


# importing Background
background #282c34
# importing BackgroundFaint
# importing BackgroundIntense
# importing Color0
color0 #3f4451
# importing Color0Faint
color16 #282c34
# importing Color0Intense
color8 #4f5666
# importing Color1
color1 #e06c75
# importing Color1Faint
color17 #c25d66
# importing Color1Intense
color9 #ff7b86
# importing Color2
color2 #98c379
# importing Color2Faint
color18 #82a566
# importing Color2Intense
color10 #b1e18b
# importing Color3
color3 #d19a66
# importing Color3Faint
color19 #b38257
# importing Color3Intense
color11 #efb074
# importing Color4
color4 #61afef
# importing Color4Faint
color20 #5499d1
# importing Color4Intense
color12 #67cdff
# importing Color5
color5 #c678dd
# importing Color5Faint
color21 #a966bd
# importing Color5Intense
color13 #e48bff
# importing Color6
color6 #56b6c2
# importing Color6Faint
color22 #44919a
# importing Color6Intense
color14 #63d4e0
# importing Color7
color7 #e6e6e6
# importing Color7Faint
color23 #c8c8c8
# importing Color7Intense
color15 #ffffff
# importing Foreground
foreground #abb2bf
# importing ForegroundFaint
# importing ForegroundIntense
# importing General

Shortcuts settings

Init

# clear the terminal screen
map cmd+k combine : clear_terminal scrollback active : send_text normal,application \x0c

# jump to beginning and end of word
map alt+left send_text all \x1b\x62
map alt+right send_text all \x1b\x66

# jump to beginning and end of line
map cmd+left send_text all \x01
map cmd+right send_text all \x05

# Map cmd + <num> to corresponding tabs
map cmd+1 goto_tab 1
map cmd+2 goto_tab 2
map cmd+3 goto_tab 3
map cmd+4 goto_tab 4
map cmd+5 goto_tab 5
map cmd+6 goto_tab 6
map cmd+7 goto_tab 7
map cmd+8 goto_tab 8
map cmd+9 goto_tab 9

# changing font sizes
map cmd+equal change_font_size all +2.0
map cmd+minus change_font_size all -2.0
map cmd+0 change_font_size all 0

map cmd+c copy_to_clipboard
map cmd+v paste_from_clipboard

Tab

map alt+1 goto_tab 1
map alt+2 goto_tab 2
map alt+3 goto_tab 3
map alt+4 goto_tab 4
map alt+5 goto_tab 5
map alt+6 goto_tab 6
map alt+7 goto_tab 7
map alt+8 goto_tab 8
map alt+9 goto_tab 9
map alt+0 goto_tab 0

# open new tab with cmd+t
map cmd+t new_tab

# switch between next and previous splits
map cmd+] next_window
map cmd+[ previous_window

Window

# open new split (window) with cmd+d retaining the cwd
map cmd+w close_window
map cmd+shif+n new_os_window
map cmd+d launch --location=hsplit --cwd=current
map cmd+shift+d launch --location=vsplit --cwd=current

Neovim

map ctrl+j kitten pass_keys.py neighboring_window bottom ctrl+j "^.* - nvim$"
map ctrl+k kitten pass_keys.py neighboring_window top ctrl+k "^.* - nvim$"
map ctrl+h kitten pass_keys.py neighboring_window left ctrl+h "^.* - nvim$"
map ctrl+l kitten pass_keys.py neighboring_window right ctrl+l "^.* - nvim$"

# the 3 here is the resize amount, adjust as needed
map alt+j kitten pass_keys.py relative_resize down 3 alt+j "^.* - nvim$"
map alt+k kitten pass_keys.py relative_resize up 3 alt+k "^.* - nvim$"
map alt+h kitten pass_keys.py relative_resize left 3 alt+h "^.* - nvim$"
map alt+l kitten pass_keys.py relative_resize right 3 alt+l "^.* - nvim$"

Moving in shell and nvim.

Session

Kitty supports session management, I added some default sessions, and opened session sockets for nvim.

The session.conf at the root is the location configuration of the session.

new_tab home
layout splits
cd ~
launch zsh
focus

new_tab work
cd ~/Develop/linuxdeepin/
launch zsh

new_tab nvim
cd ~/.config/nvim
launch zsh

Init

startup_session session.conf

# Other unix systems:
allow_remote_control yes
listen_on unix:/tmp/.kitty

dde-nixos 近期进展公告

DDE 移植兴趣小组 — Mon, 10 Apr 2023 00:00:00 +0000

目前 dde-nixos 已经分叉，mian 分支进行 v23 的维护，目前主要更新了 dtk 和部分 deepin 开头的应用， dde 开头的核心应用移植暂未实现，dbus 接口不兼容，因此目前不可日常使用。

gomod 分支用于测试使用 buildGoModule 完成构建，仅验证可行性，实际使用还需要调整硬编码相关的 patch。

日常使用 DDE 需要切换 v20 分支，会优先使用已经提交到上游的应用：

 dde-nixos = {
 url = "github:linuxdeepin/dde-nixos/v20";
 inputs.nixpkgs.follows = "nixpkgs";
 };

在 v20 分支，dtk 使用 5.6.3 不再升级，deepin 应用会保持最新的 v20 版的最新版本（不会上 6.0.0），dde 应用冻结为 1 月份打包时测试可用的版本，一般不再升级：

既除了 deepin 应用，其他应用只有在 v23 移植完成后再更新。

目前 NixOS 23.05 — Feature Freeze & Release Blockers 已经开始，进度请关注： https://github.com/NixOS/nixpkgs/issues/224457#issuecomment-1501383113

向上游贡献的主要调整：

调整 patch

在 dde-nixos 中，编写了 getPatchFrom， replaceAll 等函数帮助 patch 硬编码路径，但打包时为上游添加函数是难以接受的，因此所有的 patch 都需要使用 substituteInPlace 重写：

一个典型的例子是：https://github.com/NixOS/nixpkgs/pull/217806

改善对交叉编译

所有 deepin 启用 strictDeps，调整了 nativeBuildInputs 和 buildInputs 不规范的地方，（使用 qmake 的除外，会造成 qtwebengine 找不到，且上游已经不太关心 qmake）

strictDeps 下无法传播 qtimageformats 问题，由 NickCao 解决

ps：可以使用 nix-build -A pkgsCross.riscv64.deepin.dtkcore 尝试交叉编译。目前 x86_64 和 aarch64 可正常编译。

obs 添加玲珑构建支持

myml — Fri, 07 Apr 2023 00:00:00 +0000

obs 全称 Open Build Service，是一个开放的构建平台。相较于其他构建工具有以下优点：

支持跨平台构建（x86、arm64 等）
支持多种虚拟环境（kvm、lxc、chroot 等）
支持软件包构建（deb、rpm、pkg 等）
支持容器构建（flatpak、appimage、docker 等）
支持发型版镜像构建（debian、windows 等）

玲珑是一种新型的独立包管理工具集，致力于治理 Linux 系统下传统软件包格式复杂、交叉的依赖关系导致的各种兼容性问题，以及过于松散的权限管控导致的安全风险。

本文介绍怎么给 obs 添加玲珑构建支持，供以参考实现你自己的 obs 构建服务。

第一届小浣熊杯修 bug 大赛

deepin 社区官方博客 — Thu, 09 Mar 2023 16:29:07 +0000

deepin v23 beta 的发布在即，为了能够使相关的 bug 能够得以更快解决，并促进研发团队的协作变得更高效，我们（开源社区中心）决定在 deepin 员工内部举办小规模的 bug hunting 性质的比赛，并命名该比赛为“小浣熊杯修 bug 大赛”。而首届“小浣熊杯”也于昨天顺利落幕，那么就让我们一起了解一下这个比赛吧！

比赛介绍

如上所述，“小浣熊杯“的比赛大致内容即为在比赛时间内对已有缺陷进行修复。我们将所有参赛的员工划分为多个组，每个组除研发外也配备一个测试人员。在比赛时间周期内，研发从指定的缺陷看板中挑选自己”中意“的 BUG 进行修复，并在修复后将修复公布在相关群内，由 其他组 的测试人员进行测试。当修复被测试人员验证没有问题后，即可进行计分。最终，会以本组研发人员所修复的数量与测试人员所完成的测试数量相组合，并计算小组人均得分，最后以小组人均得分的高低决定最终排名。

小组得分的计算公示为：

小组得分 = (本组研发修复的缺陷数量 + 本组测试所验证的缺陷数量 / 3) / 小组总人数

比赛会在 https://github.com/linuxdeepin/.bug-game/ 中进行，每次比赛会创建一个看板来跟进整个比赛的实时情况，并创建一个对应的 issue 记录相关进展与结果。

另外，考虑到比赛过程中对缺陷的修复不需要经过其他研发人员的 code review ，因而可能存在实际的代码质量问题，故相关的 PR 均不要求在比赛结束前合入，相关提交仍需按照正常流程，经过有效 review 获得 approval 后合入。

首届状况介绍

首届比赛共划分了四个小队参赛，比赛时间从 3 月 7 日开始，为期两天。比赛过程与结果在这个 Issue 中汇总，最终的缺陷修复情况也可以参见这个看板。比赛过程中“修 bug”队一度领先，随后被”进击的小浣熊“队反超，最终经过了两天的”激烈比拼“后，本次比赛总计处理了 42 个 Issue，由”进击的小浣熊“队以 18.333 分的总积分获得人均积分第一夺冠。“修 bug”队紧随其后，“呆呆鹅” 与 “bug 收割小分队” 获得随后的名次。

比赛过程中，各个小组对已有 bug 的挑选与“占坑”以及测试人员对新提交修复的“抢单”是过程中最有趣的事情之一。快速挑选便于修复的 BUG 并进行有效的修复成为了获胜的关键之一，根据表象快速分析推测问题的能力，以及在陌生项目¹中快速尝试定位和修复问题的能力也变得至关重要。作为花絮，有的小组也在选择 BUG 的过程中连续发现自己所选择的缺陷实际早已在版本迭代中被修复，耗费了较多时间而造成了相对的失利，但这个过程也对现存 BUG 的有效性验证有很大的帮助²。

赛后，我们进行了比赛的颁奖，获胜队伍获得了比赛限定奖杯与荣誉证书，以及一个 deepin 主题背包。获奖队伍也进行了合影：

无论是否获奖，我们都感谢各个参赛队伍的积极参与，也希望各位能在后续的比赛中能够获得优异的成绩。

注：缺陷的修复不限于自己所维护的项目，研发人员也可以尝试修复由其他项目组所维护的缺陷。 ↩︎
或许在后续的比赛中应当为此类也算作计分项。 ↩︎

关于 deepin 社区博客

deepin 社区官方博客 — Tue, 14 Feb 2023 18:23:58 +0000

deepin 社区博客

deepin 社区公共博客平台。

用法说明

此博客平台使用了 HUGO 作为文章平台工具，进行博客文章的静态生成，并最终利用 GitHub Pages 呈现网页。故整个过程你只需按照 HUGO 的正常使用方式进行使用即可。

若未安装 HUGO，您可以从 HUGO 官方 GitHub 仓库的 Release 页面获取适用于您设备的 HUGO 版本，并放置其于 PATH 内以便调用。

安装就绪后，大致常用命令如下（在此源码仓库的根目录下执行）：

$ hugo server # 启动一个本地服务器，预览目前状态下的网站内容
$ hugo new posts/my-post.md # 创建一篇新文章，以便进行编辑
$ hugo server -D # 启用本地服务器，并且能够预览状态为草稿（`draft: true`）的文章
$ hugo -D # 生成静态页面（如果需要），生成的文件将位于 public 目录下

创建文章时，创建格式为 <分类>/<文件名>.<格式>，上面给出的例子中，分类为 posts，文件名为 my-post，格式为 md （markdown）。创建文章后，默认会使用 YAML front-matter 标记文章的一些元信息，请留意 draft 草稿状态的文章最终不会显示。

若要获取 HUGO，请参考官方文档给出的安装方式。

文章内容指导建议

向此博客平台投递文章需要经过相关人员的 review，合入后即投递完成。需要注意的是，向此处投递的文章必须是与 deepin 社区发展所相关的文章。对于与 deepin 开源社区贡献相关的个人感想或随笔等博客，可以考虑发布到 planet.deepin.org 聚合平台，此博客平台的文章也会出现 planet.deepin.org 之中。

在发布您的文章时，建议使用标签来标记您文章所相关的主题，以便读者更方便的查阅您的文章。例如 tags: ["持续集成"] 或 tags: ["指南文档", "CMake"]。另外也建议在文章的元信息中附带作者信息，例如 authors: ["张三"]（可为多人）。

改善此项目的样式风格

此项目使用了 geekblog 主题（基于 v0.5.3，有改动）。若你有任何建议，可以进行讨论并修改或提供更适合的主题。

deepin-riscv64构建环境搭建 - Zeno-sole

zeno — Fri, 03 Feb 2023 09:25:00 +0000

【摘要】pbuilder + qemu 以下操作基于debian11环境,其他环境下需注意qemu版本是否在5.2版本以上 sudo apt install pbuilder qemu qemu-user-static pigz 配置 /etc/pbuilderrc MIRRORSITE=https://m 阅读全文

DDE v23 beta 3 移植简要指南

DDE 移植兴趣小组 — Thu, 02 Feb 2023 00:00:00 +0000

编辑的话请把自己的名字加到作者名单里

DDE v23 beta3 即将随 deepin v23 beta 3 发布（你阅读到这个文章的时候可能已经发布了）。为了方便各个其它发行版的包维护者可以更方便的移植 DDE 到对应的发行版，这里提供一篇简要的移植指南，用以描述常见的移植问题和解决方案。

下面对项目名称的称呼均以 GitHub 对应的原始仓库名为准。 {.note}

概览

DDE 此次 beta2 -> beta3 的更新中，dde-application-manager 进行了大规模重构；dde-launchpad 取代 dde-launcher 成为了新的启动器/开始菜单应用；新的技术预览项目 dde-shell 和 treeland 也随此次发布提供了初步版本，以及为了服务 dde-launcher 和 dde-shell，dtk 也开始提供 Qt 6 版本。

由于这些项目的版本间互相影响，我们建议移植人员参照 deepin v23 beta3 所使用的包版本进行打包（随后会把完整的版本参照列表贴到这里），下面会对主要的部分进行详细说明。

主要组件

DTK 与 DTK6

作为 DDE 组件与应用的基础依赖，DTK 现开始提供 Qt 6 支持。适用于 beta 3 的版本参照如下：

package	version
dtkcommon	5.6.21
dtkcore	5.6.22
dtkgui	5.6.22
dtkwidget	5.6.22
dtkdeclarative	5.6.24
qt5integration	5.6.20
qt5platform-plugins	5.6.22
dtk6core	6.0.4
dtk6gui	6.0.5
dtk6widget	6.0.4
dtk6declarative	6.0.7
qt6integration	6.0.4
qt6platform-plugins	6.0.4

由于 dtkdeclarative 和 dtkgui 存在一些发布前的紧急修复，所以这两个组件存在版本号未对齐的情况。请直接参照上述表格的版本进行打包，以便确保 dtk 自身互相依赖的版本无误。

dtk6 曾对 Qt 6.2, Qt 6.4 和 Qt 6.6 均进行过适配，但我们目前的研发与测试主要使用 Qt 6.6 版本，故我们建议使用尽可能新的 Qt 6 版本。

目前，使用 dtk6 的正式组件有 dde-application-manager 以及 dde-launchpad，技术预览组件有 dde-shell, treeland。

dde-application-manager

dde-application-manager 自 1.1.0 版本起进行了完整重构（此次随 beta 3 发布的版本是 1.1.8），接口存在完全不兼容的变动。故原本依赖重构前 dde-application-manager 的应用程序和组件均需要进行更新。比较典型的组件为 dde-dock 与 dde-file-manager。

dde-launchpad

dde-launchpad 取代了 dde-launcher，原 dde-launcher 由于大量缺陷以及对旧 dde-application-manager 的强依赖，已不再可用。如果您的发行版在使用 dde-launcher，现在可以废弃 dde-launcher 并使用 dde-launchpad 替代了。

尽管在 deepin 中，dde-launchpad 使用的是 Qt 6 构建的版本，dde-launchpad 本身仍然提供了选项来控制使用 Qt 5 或是 Qt 6。我们建议在允许的情况下尽可能使用 Qt 6 而不是 Qt 5，以及无论 Qt 5 或是 Qt 6 支持，请都不要忘记安装 qt5/6integration 插件以及 qt5/6platform-plugins，否则 dde-launchpad 可能会缺失圆角与模糊效果。同样，强烈建议配合最新 DTK 版本构建来获得最佳显示效果。

另外，随 dde-launchpad 一并发布了 dde-application-wizard 项目。此项目是一个守护进程，提供对旧的 dde-application-manager 所提供的卸载服务接口的兼容支持，但可被移植到支持 packagekit 的发行版，故您可以考虑打包移植此组件。如果您的发行版不支持 packagekit，则可考虑暂时 patch dde-launchpad 来隐藏菜单中的卸载按钮，后续 dde-launchpad 会提供 DConfig 来便于发行版定制这些菜单项。

技术预览组件

技术预览阶段的组件均可酌情决定是否打包。

dde-shell

dde-shell 目前是技术预览阶段的项目。dde-shell 旨在将 DDE 桌面环境插件化与模块化，降低开发难度，使各个组件的替换变得更加容易，并且提供更好的桌面环境集成支持。

dde-shell 目前包含 shell 本体，以及预制的新 dock 插件和通知中心插件。

treeland / ddm

同时我们放弃了对 deepin-kwin wayland 的支持（更新 dde-session 后会屏蔽入口），DDE 所有 wayland 相关的支持均由 Treeland 提供。

deepin-im

获取移植帮助

如果您希望得到移植相关的帮助，请考虑加入我们 DDE 移植小组的在线交流群（下列房间有桥接，任选其一即可），一起展开相关的交流：

Matrix 群：#dde-port:deepin.org
Telegram 群：https://t.me/ddeport

dde-nixos 2023 年 1 月成果展示

DDE 移植兴趣小组 — Mon, 30 Jan 2023 00:00:00 +0000

本月对 NixOS DDE 做了进一步完善，已经比较适合在实体机上使用了。

现在 deepin v23 的版本即将发布，github 大部分 DDE 软件已经升级到了 23 版本，由于 20 和 23 版本不完全兼容，dde-nixos 将使用 v20 分支继续维护/测试 v20 版本的 DDE, main 分支尝试 v23 版本。

目前的主要工作是将 v20 版本的移植工作转移到上游，方便更多用户使用。同时 review 机制也可以找到并处理现有写法的不规范之处。Nixpkgs 合并进程请关注：https://github.com/linuxdeepin/dde-nixos/issues/9

目前已经有一部分应用可在官方仓库下载。

此外 @SamLukeYes 构建了 NixOS DDE 的 iso，可以直接使用： https://github.com/SamLukeYes/nixos-dde-iso/releases/tag/22.11.20230113

dtk
- 统一升级到 5.6.3
- qt5integration 使用 5.6.4 ：修复通知中心图标缺失问题/修复 log 中大量 create icon [] engine failed.[theme:] 问题
dde-control-center:
- 禁用系统版权协议模块（仅适配deepin/uos）
- (dde-api) 修复无法识别本机语言的问题
- 修改语言（locale）功能在 NixOS 中无法实现，属于正常现象
- 适配系统版权信息（通过 /etc/deepin-installer.conf 配置实现）
- 修复明暗主题，图标光标主题缺失（go-lib isDir 判断错误）
dde-daemon
- 修复 nix 的 wrapped 应用后无法通过 verifyExe 校验问题
- 清理无用的硬编码 patch
deepin-kwin 相关软件：
- 已经切换至 linuxdeepin 仓库的 tag 版本
dde-account-faces
- /var 路径文件改用 systemd.tmpfiles 模块管理
deepin-system-monitor
- 修复 dock 插件显示问题
配置 Garnix CI
- 通过 Garnix 自动构建 dde-nixos 的软件，支持 x86 和 arm
- 使用 Garnix 提供的 binary caches，可以无需编译即可使用 DDE, 用法见项目 readme
gio-qt
- 修复文档编译失败
deepin-boot-maker
- 修复多处硬编码路径，修复无法识别 u 盘的问题
dpa-ext-gnomekeyring
- 修复硬编码
deepin-font-manager
- 修复系统字体识别错误
dde-file-manager
- 修复新版空格预览崩溃
- 处理插件硬编码路径
dde-app-services
- 修复 GUI 编辑器无法读取其他应用配置问题
dde-network-core
- 修复控制中心插件翻译

其他：

新增 security.pam.services.dde-lock，代替 dde-lock 所使用的 common-auth
新增 deepin-orc 支持
修复对 deepin-anything 的支持
默认安装 onboard， dock 插件使用
处理 updateDbusEnvironment 未生效的问题：https://github.com/NixOS/nixpkgs/issues/209847
清理 dde 模块中非必要启用的 services
优化 nix 函数结构，dtk 不再使用列表，改用 propagatedBuildInputs

目前已知的问题：

qt 应用启动器启动不是deepin主题，但通过 deepin-terminal 启动是：

qt5integration 未全局安装，安装后虽然 qt 主题无问题，但是会导致启动器缺失图标等问题。建议 qt 继续使用 breeze 主题

lightdm 不是 deepin 主题

目前 deepin-greeter 无法正常使用，不过使用其他主题或者用 sddm 也是可以启动 DDE 的。

窗口模糊特效缺失

deepin-kwin 的问题，等待修复。通过控制中心关闭再打开特效，可以临时解决。

Snippet

deepin 文档小组 — Tue, 27 Dec 2022 01:24:05 +0000

vscode snipets 用户代码片段使用指南

snipets简介

snipets 我愿意称为程序员的ctrl+c ctrl+v最大的竞争对手，sniptes适用于遇到很多重复代码却又没法去提取代码特点抽象成类的情况。比如写注释的时候。

这是一个极好的工具用于高效率办公（摸鱼）

vscode 打开snipets

然后你就需要选择对应的语言，这里我以doxygen注释文件为例子：打开之后会得到这样一个文件：

{
// Place your snippets for doxygen here. Each snippet is defined under a snippet name and has a prefix, body and
// description. The prefix is what is used to trigger the snippet and the body will be expanded and inserted. Possible variables are:
// $1, $2 for tab stops, $0 for the final cursor position, and ${1:label}, ${2:another} for placeholders. Placeholders with the
// same ids are connected.
// Example:
// "Print to console": {
// "prefix": "log",
// "body": [
// "console.log('$1');",
// "$2"
// ],
// "description": "Log output to console"
// }
}

这个文件都是注释组成，自然也没有任何功能，我们要做的是对其进行修改，以支持我们自己的代码片段

代码片段的解读

先以一个比较简单的例子作为内容：

{
 // Place your snippets for doxygen here. Each snippet is defined under a snippet name and has a prefix, body and
 // description. The prefix is what is used to trigger the snippet and the body will be expanded and inserted. Possible variables are:
 // $1, $2 for tab stops, $0 for the final cursor position, and ${1:label}, ${2:another} for placeholders. Placeholders with the
 // same ids are connected.
 // Example:
 // "Print to console": {
 // "prefix": "log",
 // "body": [
 // "console.log('$1');",
 // "$2"
 // ],
 // "description": "Log output to console"
 // }
 "dox dtkwidget": {
 "prefix": "da",
 "body": [
 "@fn void Dtk::Widget::DAlertControl::${2:function}",
 "@brief ${3:info}"
 ]
 }
}

我们来逐行解释：dox dtkwidget指的是这个代码片段的命名，你可以使用任何你喜欢的命名来代替它

然后就是一个键值对 “prefix” 的值一般是一个字符串，这个字符串也是可以自定义的，含义就是你在代码文件里面输入这个字符串（在某一行的开头）后会弹出选项询问你是否使用代码片段：比如这个就是da,你在某一行的开头打出da这俩字符，就会弹窗询问你是否替换

同时会显示对于代码片段的命名

body键值对就是最重要的一部分，这个里面就保存的你需要的代码片段，

请注意，其中每一行都代表的是你之后生成的代码的一行，如上代码片段生成的代码就是

@fn void Dtk::Widget::DAlertControl::function
@brief info

如果你现在已经复制了我的代码片段，不妨新建一个dox文件试试。打出da之后会弹出选项，按tab键确认之后就会出现这个代码，不过会让你填写function的值，填写完毕之后就按tab键切换到info需要你填写info的值

不过这样还不是代码片段的全部实力，它还能更强大点：

 "dox about dtkwidget": {
 "prefix": "dd",
 "body": [
 "@property ${1|QColor,void,bool|} Dtk::Widget::DAlertControl::${2:function}",
 "@brief 返回${3:info}",
 "",
 "@fn void Dtk::Widget::DAlertControl::set${2/(.*)/${1:/capitalize}/i}",
 "@brief 设置${3:info}",
 "@sa DAboutDialog::${2:function}"
 ]
 }

比如这样

你可以自己试试这个会发生什么

对的它还支持正则表达式的替换

现在看看我正在用的doxygen的代码片段

{
"dox about DtkGui": {
"prefix": "dd",
"body": [
"@property Dtk::Gui::DDciIconPalette::${2:function}",
"@brief ${2}属性",
"@sa READ方法: void Dtk::Widget::DDciIconPalette::${2:function}",
"@sa WRITE方法: void Dtk::Widget::DDciIconPalette::set${2/(.*)/${1:/capitalize}/i}",
"",
"@fn ${1|QColor,void,bool|} Dtk::Widget::DDciIconPalette::${2:function}",
"@brief 返回${3:info}",
"@sa DDciIconPalette::${2:function}",
"",
"@fn void Dtk::Widget::DDciIconPalette::set${2/(.*)/${1:/capitalize}/i}",
"@brief 设置${3:info}",
"@sa DDciIconPalette::${2:function}"
]
},
"dox dtkwidget": {
"prefix": "da",
"body": [
"@fn void Dtk::Widget::DDciIconPalette::${2:function}",
"@brief ${3:info}"
]
}
}

我可以通过这个代码片段一键生成属性的get和set方法的doxygen注释

DDE 移植小组成果展示

DDE 移植兴趣小组 — Mon, 12 Dec 2022 00:00:00 +0000

自小组成立以来，已经为 DDE 的移植做出了很多贡献，本文做出了一些总结。如有补充或批改，可向 sig-dde-porting 提出 pr。

NixOS 的移植从今年 3 月开始，到现在已经有了实用的可能，今后会用一篇文章单独介绍。未来会每月更新进展，关注的同学可以订阅本站 rss。

今年改善可移植性的一些努力

修复依赖特定 kwayland 无法在其他发行版编译的问题（为项目增加禁用wayland的option）：

deepin-system-monitor，dde-clipboard，dde-session-shell…

修复安装路径硬编码问题

29 个相关 pr https://github.com/linuxdeepin/developer-center/issues/3167

减少代码中的硬编码问题

16 个相关 pr https://github.com/linuxdeepin/developer-center/issues/3374

编译 flag 直接覆盖的问题

大约 8 处

修复 as-need 参数 break 了部分连接器:

10 个相关 pr https://github.com/linuxdeepin/developer-center/issues/3345

完善项目关于 pkg-config/Config.cmake 的问题(如写死路径，版本号错误，引入依赖检查不完善等等)

至少 17 个相关 pr，事实上应该远多于 17，存在多个修改顺便提在一个 pr 的情况。

使用 dpkg-architecture 判断架构其他发行版无法使用问题

4 处以上

避免绝对路径头文件：

解决 2 处，但仍有 1 处难以处理（https://github.com/linuxdeepin/dde-session-shell/pull/120）

dde-kwin 问题

justforlxz 已经多次修复 dde-kwin 对 kwin 的适配问题，但每次 kwin 每次更新都会重新带来很多问题。正在移植中的 deepin-kwin 将会解决这个麻烦，目前可以使用 Arch（aur）或者 dde-nixos 先行体验。

处理 deepin-wallpapers 非自由协议问题（拆包）

dde-nixos 近期进展

dtkcore：
- 其他发行版调用 uosType 直接返回 UosTypeUnknown，避免无意义的报错刷屏
- 完善 isDDE 函数判断
- deepin-os-release 判断是其他发行版后不会输出 deepin/uos 特有参数
dde-control-center:
- 提供禁用生物认证模块的 option
- 修复无法设置头像问题
- 修复密码校验无法通过的问题
- 修复系统信息/关于本机的显示问题：
  - 启用不应隐藏的“计算机名”，“产品名称”
  - 隐藏“版本”（社区版/专业版）
  - 替换为 NixOS 的 logo
  - 隐藏修改 “计算机名” 的功能
- 隐藏用户体验模块，禁用对应 dbus 调用，修复通用模块卡钝问题
- 修复显示内存为 0 的问题
deepin-movie:
- 修复格式支持不完整的问题（修复 libPath 硬编码）
- 修复一个崩溃问题
dde-grand-search:
- 修复调用 dde-grand-search-daemon 的权限验证
deepin-screen-recorder：
- 修复2个导致崩溃的问题
- 修复命令行启动无法录屏的问题（dock插件仍然有此问题）
修复 GStreamer 音频播放：
- 需要设置依赖以及 GST_PLUGIN_SYSTEM_PATH_1_0
- 涉及 deepin-music deepin-voice-note deepin-movie 和 dde-introduction
deepin-editor：
- 修复主题路径硬编码造成的界面异常
deepin-compressor:
- 修复无法加载自身插件的问题
修复个别图标丢失的问题（部分 dci 图标需要 qtimageformats 支持）

伟大的第一步

deepin M1 适配小组 — Thu, 22 Sep 2022 07:46:56 +0000

这是第一篇 deepin-m1 sig 的博客，我非常的激动，因为 deepin 现在已经可以在 m1 设备上启动了。

目前在 m1 上启动 Linux 的项目进展最快的是 Asahi Linux，他们是 Linux m1 的项目发起者，同时也是 Asahi Linux 的维护者，目前 Asahi Lina 正在努力开发 m1 GPU 驱动，已经实现了绝大部分底层的功能，正在做渲染队列的工作，相信很快就可以为 Linux 带来开源的 m1 GPU 驱动。

debian 和 fedora 也基于 Asahi installer 制作了发行版本，我们的工作也是从这里开始的。

经过分析，发现 Asahi installer 已经预留了更换 rootfs 的接口，这使得我们的工作异常顺利，很快便完成了第一版的安装文件。

目前 m1 启动 Linux 的流程是先启动 Asahi m1n1，由 m1n1 启动 u-boot，再由 u-boot 启动 grub。

m1n1 是一个非常不错的项目，可以通过 usb 进行串口调试，方便进行驱动逆向和调试，也可以测试启动 elf。

在 m1 上安装 Linux，需要先进入一次 macOS 的恢复模式，利用恢复模式将文件内容写入，目前这已经是最好的解决方案了，目前小组正在整理相关文档和脚本，预计下个月可以对外提供正式的安装脚本和视频教程。还有很多功能没有准备好，例如一些 x86 软件无法运行，m1 只支持 16k 页内存等，可能会带来很多软件的兼容性问题，我们也欢迎更多的人加入 deepin-m1 sig 组中，提供更多的帮助。

enjoy live!

deepin doc doc go 小组现已建立！

deepin 文档小组 — Fri, 16 Sep 2022 06:00:00 +0000

这是一个模板文章。各个 SIG 在实际使用此博客模板时可根据实际需求对此模板进行任何调整。

我们要求 deepin 社区中的小组每季度至少能有一到两次对公众公开的小组成果展示，用以分享成果，使得社区大众均能受益。通过使用此博客模板，SIG 即可直接在自己的小组博客站点中提供小组成果的相应博客介绍，而 SIG 委员会以及其它感兴趣的小组即可直接利用 RSS 订阅来获得相应的内容更新。

对于成果公示类的文章，您即可通过“成果公示”或类似的标签来标记文章，这样，在此标签内的文档就会被生成到同一标签类别的 RSS 之中，以供订阅了。

XXXX 小组现已建立！

Deepin desktop virtualization SIG — Fri, 16 Sep 2022 06:00:00 +0000

这是一个模板文章。各个 SIG 在实际使用此博客模板时可根据实际需求对此模板进行任何调整。

XXXX 小组现已建立！

Deepin system cicd SIG — Fri, 16 Sep 2022 06:00:00 +0000

这是一个模板文章。各个 SIG 在实际使用此博客模板时可根据实际需求对此模板进行任何调整。

规范导出和使用 Config.cmake 文件

DDE 移植兴趣小组 — Fri, 16 Sep 2022 06:00:00 +0000

生成 Config.cmake 文件

生成 Config.cmake 文件路径要求与 pkg-config 一致

应该提供 FooConfig.cmake.in 使用 FULL 版本的 GNUInstallDirs 变量替换路径

使用 find_dependency 代替 find_package

cmake 官方提供了 CMakeFindDependencyMacro 模块，专门用在 Config.cmake 文件中，find_dependency 和 find_package 用法完全相同，因此可以简单的把原来的 find_package 替换成 find_dependency。

find_dependency 的优点是如果 A 的 Config.cmake 寻找 B 的，如果失败 find_package 只会提示 B 的错误，而 find_dependency 还在报错中输出调用链，清晰显示是谁在找 B。

find_dependency 应该在 set 路径之后。

与 pkg-config 的 Requires 类似，这里只 find 传播的构建依赖。

使用 configure_package_config_file 代替 configure_file

使用 FULL 版本的 GNUInstallDirs 变量虽然正确，但还有一个缺陷，生成的是绝对路径，库必须安装到对应目录才可以。而 configure_package_config_file 可以自动计算相对的路径，适用性更广泛。

configure_package_config_file(misc/PkgNameConfig.cmake.in
 ${CMAKE_CURRENT_BINARY_DIR}/PkgNameConfig.cmake
 INSTALL_DESTINATION "${CMAKE_INSTALL_LIBDIR}/cmake/PkgName"
 PATH_VARS INCLUDE_INSTALL_DIR TOOL_INSTALL_DIR
)

INSTALL_DESTINATION 是 Config.cmake 的安装路径，但这里并不会安装，只是用来计算相对路径的，所以 install 还是需要写的。

PATH_VARS 传入 PkgNameConfig.cmake.in 里会用到的路径变量。

为了使用 configure_package_config_file，Config.cmake.in 也需要做出以下变化：

在开头写一行 @PACKAGE_INIT@，这会展开生成 CMakePackageConfigHelpers 提供的宏，包括set_and_check，check_required_components。
使用 set_and_check 替代 set 设置路径，可以在引入时检查对应的路径文件是否存在。（注意如果拆包了其他包的文件就不要 check 了）。
路径变量前面加 PACKAGE，如 @INCLUDE_INSTALL_DIR@ 改成 @PACKAGE_INCLUDE_INSTALL_DIR@，需要上面 configure_package_config_file 的 PATH_VARS 参数传进来。
文件后面使用 check_required_components(PkgName) 检查组件，即使没有拆分组件也应该检查，明确告诉 cmake 该包没有组件。

使用 Targets

对于新增的库，建议使用新式 cmake 写法，使用 Targets，而非手动设置路径：

建议参考： Installing a Config.cmake file

使用 find_package 引入库

find_package 有两个模式，Modules Mode 和 Config Mode，在 Modules Mode下，find_package(PkgName) 会寻找命名为 FindPkgName.cmake 的模块，由此模块负责寻找，这种模块一般是由 cmake 官方提供或者调用者自己编写。Config Mode 就是寻找 PkgNameConfig.cmake 模块了，由库自己提供。

find_package(DtkCore)
message("${DtkCore_VERSION}") # 6.2 以前没有提供
message("${DtkCore_LIBRARIES}")
message("${DtkCore_LIBRARY_DIRS}") # ！没有提供
message("${DtkCore_INCLUDE_DIRS}") # ！没有提供

find_package(Dtk REQUIRED Core Gui Widget)
# 与 pkg_check_modules 不同，后面是同一（组）软件提供的不同 components，等价于：
find_package(Dtk)
find_package(DtkCore)
find_package(DtkGui)
find_package(DtkWidget)

find_package 提供的变量请检查 Config.cmake 提供了什么，不像 pkg_check_modules 那样命名统一，在 6.2 以前，提供 DTKCORE_INCLUDE_DIR， 6.2 之后使用 DtkCore_INCLUDE_DIR（旧版变量仍保留）。

使用 find_package 引入 dtk 的软件，如果用了 DtkCore_INCLUDE_DIRS 请修改，这是 pkg_check_modules 引入才有的变量，另外 DTKCORE_INCLUDE_DIR 升级后建议换成 DtkCore_INCLUDE_DIR。Gui，Widget 同理。

参考资料：

编写 FindXXX.cmake 模块

对于没有提供 pkg-config 也没有提供 Config.cmake 并且 cmake 官方没有提供对应模块的，建议自行写一个 FindXXX.cmake 模块

通过 find_path，find_library 函数计算出 foo_INCLUDE_PATH, foo_LIBRARY。
通过 FindPackageHandleStandardArgs 模块提供的 find_package_handle_standard_args 根据 foo_INCLUDE_PATH, foo_LIBRARY 是否有值设置 foo_FOUND，这样是让 find_package 识别此模块所需要的。
一般会把 foo_INCLUDE_PATH, foo_LIBRARY 标记为高级（mark_as_advanced），不再 cmake gui 显示。

编写模块自由度很高，还可以根据需求检查 check_function_exists，check_symbol_exists 影响 foo_FOUND 而且只需要编写一次，其他项目可以直接复用。

修改示例：

https://github.com/linuxdeepin/image-editor/pull/28

dtkcommon 相关

使用 dconfig_override_files 请不要忘记通过 find_package(Dtk) 引入 dtkcommon 提供的模块，而不是靠 DtkWidget 的传播依赖（实际上不应该传播 dtkcommon 的）。

规范导出和使用 pkg-config 文件

DDE 移植兴趣小组 — Fri, 16 Sep 2022 06:00:00 +0000

使用 pkg-config

pkg-config 是一个在源代码编译时查询已安装的库的使用接口的计算机工具软件。pkg-config原本是设计用于Linux的，但现在在各个版本的BSD、windows、Mac OS X和Solaris上都有着可用的版本。

它输出已安装的库的相关信息，包括：

C/C++编译器需要的输入参数
链接器需要的输入参数
已安装软件包的版本信息

使用 cmake 生成 .pc 文件

一个比较规范的 foo.pc.in 如下：

prefix=@CMAKE_INSTALL_PREFIX@
exec_prefix=${prefix}
libdir=@CMAKE_INSTALL_FULL_LIBDIR@
includedir=@CMAKE_INSTALL_FULL_INCLUDEDIR@/libimageviewer
Name: foo
Description: foo is a demo lib
Version: @PROJECT_VERSION@
Libs: -L${libdir} -lfoo
Cflags: -I${includedir}
Requires: Qt5Core Qt5Gui Qt5Widgets

这里的 Name 是显示的名称，文件名才是搜索用，显示名一般不要全部大写。

Requires：设置 foo 的依赖，这里有2个条件：

必须是传播的构建依赖，即某软件构建依赖 foo，构建环境必须有 bar 才可以编译
必须是提供 .pc 文件的依赖

另外不要忘记加 -L 参数（链接库地址），-I 参数（头文件地址）。

其中路径问题（libdir/includedir）这里再强调一下，不规范做法：

prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include/foo

这种是硬编码路径，可移植性非常差。

prefix=@CMAKE_INSTALL_PREFIX@
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include/foo

相比上种方法，prefix 使用 cmake 变量，可以应对 prefix 不是 /usr 的情况了。

prefix=@CMAKE_INSTALL_PREFIX@
exec_prefix=${prefix}
libdir=${prefix}/@CMAKE_INSTALL_LIBDIR@
includedir=${prefix}/@CMAKE_INSTALL_INCLUDEDIR@/foo

相比上种方法，lib/include 目录使用 GNUInstallDirs 变量代替，灵活度更高。

但是，这种并非最好的，因为（1）GNUInstallDirs 有特殊的拼接规则，如 PREFIX=/，LIBDIR=lib，应该拼接成 /usr/include 而非 /include。（2）CMAKE_INSTALL_LIBDIR 虽然默认是相对路径，但允许被直接设置成绝对路径。

写在 .pc.in 只能简单拼接，无法判断特殊情况，最好由 cmake 进行拼接。GNUInstallDirs 提供 FULL 版本变量（本文第一个示例）就是智能拼接出来的，建议使用。当然，基于此自行设置变量也可以： set (INCLUDE_INSTALL_DIR "${CMAKE_INSTALL_FULL_INCLUDEDIR}/libdtk-${CMAKE_PROJECT_VERSION}/DCore")。

使用 qmake 生成 pkgcconfig 文件

CONFIG += create_prl create_pc
# 生成 .pc 文件需要 .prl 中间文件，如果不需要可以使用 no_install_prl
QMAKE_PKGCONFIG_NAME = foo
QMAKE_PKGCONFIG_DESCRIPTION = foo is demo
QMAKE_PKGCONFIG_INCDIR = $${HEADERDIR}
QMAKE_PKGCONFIG_LIBDIR = $${LIBDIR}
QMAKE_PKGCONFIG_DESTDIR = pkgconfig

其中的 HEADERDIR，LIBDIR 是需要在 .pro 文件中设置的安装路径。

cmake 使用 pkg-config

不要混淆 find_package 和 pkg_check_modules

cmake 导入

find_package(PkgConfig REQUIRED) # 导入此模块才可以使用 pkg_check_modules
pkg_check_modules(DtkCore REQUIRED dtkcore)
message("${DtkCore_VERSION}")
message("${DtkCore_LIBRARIES}") # 对应 -l 参数
message("${DtkCore_LIBRARY_DIRS}") # 对应 -L 参数
message("${DtkCore_INCLUDE_DIRS}") # 对应 -I 参数
pkg_check_modules(Dtk REQUIRED dtkcore dtkgui dtkwidget)
message("${Dtk_LIBRARIES}")
message("${Dtk_LIBRARY_DIRS}")
message("${Dtk_INCLUDE_DIRS}")

参考资料

https://cmake.org/cmake/help/latest/module/FindPkgConfig.html

qmake 使用 pkg-config

CONFIG += link_pkgconfig
PKGCONFIG += foo

规范设置编译参数

DDE 移植兴趣小组 — Fri, 16 Sep 2022 06:00:00 +0000

CMake 中有许多关于编译器和链接器的设置。当你需要添加一些特殊的需求，你应该首先检查 CMake 是否支持这个需求，如果支持的话，你就可以不用关心编译器的版本，一切交给 CMake 来做即可。更棒的是，你可以在 CMakeLists.txt 表明你的意图，而不是通过开启一系列标志 (flag) 。

优化参数(-O0/-O1/-O2/-O3/-Ofast/-Os) 和 debug 参数（-g）

CMAKE_BUILD_TYPE 包括 Debug, Release, RelWithDebInfo 和 MinSizeRe 4 个选项

它们对应参数是（不同编译平台可能有少许区别）：

Release: -O3 -DNDEBUG
Debug: -O0 -g
RelWithDebInfo: -O2 -g -DNDEBUG
MinSizeRel: -Os -DNDEBUG

这些参数可以通过 CMAKE_CXX_FLAGS_DEBUG，CMAKE_CXX_FLAGS_RELEASE… 查看，并不直接体现在 CMAKE_CXX_FLAGS 中。

CMAKE_BUILD_TYPE 的默认值不是Release，也不属于上面4种，而是空值，即不附加任何参数。

全局（或非debug模式）设置 -O3：

建议改为将 CMAKE_BUILD_TYPE 设置默认 Release

https://github.com/ros-infrastructure/bloom/issues/327

Release 模式加 O3, Debug 模式加 -g 等等

不用加，这些都是无用功

Release 模式加 -g

如果软件发行版本需要 debug 符号，请用 RelWithDebInfo 模式

Debug 加 -O3

高级别的优化会严重影响 debug 调试，可以改用 -Og，它允许不影响调试的优化

同时有 -O1 -O3

-O0/-O1/-O2/-O3/-Ofast 开启的优化参数前依次递增，是完全的子集关系，不是多多益善的。 -Os 是在 -O2 的基础上，尽可能优化程序大小。

Release 模式使用 -Ofast 或其他优化级别。

最好是 string(REPLACE "-O3" "-Ofast" CMAKE_CXX_FLAGS_RELEASE ${CMAKE_CXX_FLAGS_RELEASE})，这样就没有原来的-O3了如果是是降低优化基本，则必须这样替换。

参考资料：

https://stackoverflow.com/questions/48754619/what-are-cmake-build-type-debug-release-relwithdebinfo-and-minsizerel

de

参考修改：

https://github.com/linuxdeepin/dtkcore/pull/114

c++标准版本 (比如 -std=c++11)

直接使用 set(CMAKE_CXX_STANDARD 11)

部分项目设置了 CMAKE_CXX_STANDARD 为 14/17, 又加了参数 -std=c++11，这是冲突的，请检查。比如： https://github.com/linuxdeepin/deepin-movie-reborn/blob/0a08e29e78c4f35f787b999d857f696f804f8641/CMakeLists.txt#L18

Hardening

DEB_BUILD_HARDENING_FORMAT (gcc/g++ -Wformat -Wformat-security -Werror=format-security) DEB_BUILD_HARDENING_FORTIFY (gcc/g++ -D_FORTIFY_SOURCE=2) DEB_BUILD_HARDENING_STACKPROTECTOR (gcc/g++ -fstack-protector-strong) DEB_BUILD_HARDENING_PIE (gcc/g++ -fPIE -pie) DEB_BUILD_HARDENING_RELRO (ld -z relro) DEB_BUILD_HARDENING_BINDNOW (ld -z now)

as-need 参数

已知 as-need 参数 break 了 mold 连接器，可用 as-needed 代替。相关：https://github.com/linuxdeepin/developer-center/issues/3345

dl 库

如果你需要链接到 dl 库，在 Linux 上可以使用 -ldl 标志，不过在 CMake 中只需要在 target_link_libraries 命令中使用内置的 CMake 变量 ${CMAKE_DL_LIBS} 。这里不需要模组或者使用 find_package 来寻找它。（这个命令包含了调用 dlopen 与 dlclose 的一切依赖）

程序间优化(Interprocedural optimization)

INTERPROCEDURAL_OPTIMIZATION，最有名的是 链接时间优化 以及 -flto 标志，这在最新的 CMake 版本中可用。你可以通过变量 CMAKE_INTERPROCEDURAL_OPTIMIZATION（ CMake 3.9+ 可用）或对目标指定 INTERPROCEDURAL_OPTIMIZATION 属性来打开它。在 CMake 3.8 中添加了对 GCC 及 Clang 的支持。如果你设置了 cmake_minimum_required(VERSION 3.9) 或者更高的版本（参考 CMP0069），当在编译器不支持 INTERPROCEDURAL_OPTIMIZATION 时，通过变量或属性启用该优化会产生报错。你可以使用内置模块 CheckIPOSupported 中的 check_ipo_supported() 来检查编译器是否支持 IPO 。下面是基于 CMake 3.9 的一个例子：

include(CheckIPOSupported)
check_ipo_supported(RESULT result)
if(result)
 set_target_properties(foo PROPERTIES INTERPROCEDURAL_OPTIMIZATION TRUE)
endif()

位置无关的代码

在 g++ 中，对编译生成动态库是 -fPIC/-fpic，对生成可执行文件是 -fPIE/-fpie。

如果要把静态库链接到动态库，这一选项是必须的。其他情况也建议开启，可以防范一些内存攻击。

在 cmake 中，对于动态库（SHARED and MODULE library），这一选项是默认开启的。对于静态库，在 cmake 3.14 版本之后（CMP0083 新标准），默认值是 POSITION_INDEPENDENT_CODE，而该值默认为假。

可以通过 set(POSITION_INDEPENDENT_CODE True) 让静态库默认增加 “-fpic” 编译。

最好通过 set_property 设置此选项：set_property(TARGET foo PROPERTY POSITION_INDEPENDENT_CODE TRUE)，foo 为对应静态库或者可执行程序。

此外，推荐使用 check_pie_supported()，检查一下编译器是否支持。

参考资料：

-lpthread

POSIX thread 是基于 C/C++ 的标准线程库。在 cmake 3.1 以上的版本提供了 FindThreads 模块，如果设置 THREADS_PREFER_PTHREAD_FLAG 变量，会优先使用 pthread。

set(THREADS_PREFER_PTHREAD_FLAG ON)
find_package(Threads REQUIRED)
target_link_libraries(my_app PRIVATE Threads::Threads)

参考文档：

https://modern-cmake-cn.github.io/Modern-CMake-zh_CN/chapters/features/small.html

设置时不要覆盖之前的选项

错误示例：set(CMAKE_CXX_FLAGS “-Wall”) 正确示例：set(CMAKE_CXX_FLAGS “${CMAKE_CXX_FLAGS} -Wall”)

如果确实有覆盖的要求，请在源码注释说明，因为一般出现覆盖 flag 很可能是失误。

判断架构

遗留代码有使用 dpkg-architecture 判断的，改用 CMAKE_SYSTEM_PROCESSOR。

dpkg-architecture 是 debian 系特有的，并不通用。除了 deb 安装器等不考虑像其他发行版移植的应用，不要在 CMakeList 里使用 dpkg 系列命令。

https://github.com/linuxdeepin/dde-dock/pull/681

CMAKE_L_FLAGS

部分项目使用了 CMAKE_L_FLAGS，这不是 cmake 标准的变量，这是想用 CMAKE_EXE_LINKER_FLAGS ？

glib-compile-schemas

gsettings schemas 安装后需要编译一下（一般目录是 /usr/share/glib-2.0/schemas）才能使用，这个应该是安装后进行的，用对应目录所有 gschema.xml 再编译出一个 gschemas.compiled 文件。

像下面这样在 CMakeList.txt 编译是不需要的： install(CODE "execute_process(COMMAND glib-compile-schemas ${CMAKE_INSTALL_PREFIX}/share/glib-2.0/schemas)") 相关修改

尽可能避免使用 hardcode 路径

DDE 移植兴趣小组 — Fri, 16 Sep 2022 06:00:00 +0000

可执行程序

判断某个可执行程序是否存在

不推荐做法：根据硬编码路径判断某个文件是否存在。比如判断 QFile().exists(/usr/bin/Foo)。

推荐做法：根据 PATH 寻找可执行文件, 一般不需要自行读取 PATH，比如 QT 可以使用：

Exist = !QStandardPaths::findExecutable("Foo").isEmpty();

比如 glib 可以使用 find_program_in_path。

修改示例：

执行某个可执行程序

同样，推荐用 PATH 寻找，尽量不使用绝对路径。

Qt 的 QProcess 会自动处理 PATH 环境变量，因此 QProcess::execute("/usr/bin/touch", QStringList() << sessionCacheFile) 可以直接改成 QProcess::execute("touch", QStringList() << sessionCacheFile)。

修改示例：

https://github.com/linuxdeepin/deepin-downloader/pull/27

动态库路径

尽量不要硬编码 /urs/lib

qt 应用可以使用 QLibraryInfo::location(QLibraryInfo::LibrariesPath)

头文件

绝对不要有 #include </usr/include/xxx.h> 这种代码，c/c++ 头文件会自动在 /usr/include 里寻找，直接使用 #include <xxx.h> 。

此外，如果库提供了 pkg-config 文件，提供的 -I 参数会指定头文件位置，如果提供 Config.cmake （cmake用）文件，一般会提供 Foo_INCLUDE_DIR 变量，如果提供 .pri （qmake 用）文件，由 QT.foo.includes 提供头文件位置。xxx.h 是相对提供的路径寻找。

对于没有提供任何开发文件的库，也可以使用 cmake 提供的 CheckIncludeFile 模块寻找头文件。

应用数据（/use/share）

/usr/share，一般保存与架构无关的只读数据。此目录同样不应该硬编码，在 XDG 规范中，这种数据的目录使用环境变量 XDG_DATA_DIRS 设置，如果读不到对应环境变量再去读取 /usr/local/share:/usr/share。

使用 qt 的应用该类型硬编码路径应该使用 QStandardPaths 或者 libqtxdg 代替。

参考：XDG Base Directory

在此目录寻找某文件，推荐使用 QStandardPaths::standardLocations 参考修改：

https://github.com/0xd34df00d/leechcraft/commit/32bf44704e156eaf6ada672e18febf64d9fd279f

/usr/share/applications

直接使用 QStandardPaths::standardLocations(QStandardPaths::ApplicationsLocation)

/usr/share/AppName

读取本应用数据，qt 软件可以使用 QStandardPaths::standardLocations(QStandardPaths::AppLocalDataLocation)

导入翻译

部分应用导入翻译使用了 /usr/share 示例, 应该改为使用 QStandardPaths::standardLocations(QStandardPaths::GenericDataLocation), 此外使用了 dtk 的应用是直接用 DApplication 的 loadTranslator 导入翻译。

Shebangs

#!/bin/bash -> #!/usr/bin/env bash
#!/usr/bin/python -> #!/usr/bin/env python

并非所有系统都有 /bin 目录和 /usr/bin 目录，比如 NixOS 和 GNU Guix 操作系统。 env 可以根据环境变量 $PATH 寻找可执行程序（如 bash），比硬编码路径更加灵活，可以提高可移植性。

不过并非所有脚本都适合使用 env, 有 2 种情况：

对安全性要求高的脚本（如以 root 权限运行），硬编码可以避免通过相关 PATH 让 bash 指向恶意程序。
带有参数的 Shebangs 头，如 #!/usr/bin/perl -w 不能改成 #!/usr/bin/env perl -w

对除此之外的大部分的 Shebangs 脚本来说，使用 env 是更好的方案。

参考资料：

在 GNU/Linux 中使用 GNUInstallDirs 优化 cmake 安装路径

DDE 移植兴趣小组 — Fri, 16 Sep 2022 06:00:00 +0000

使用 GNUInstallDirs.cmake模块

在指定安装路径时，应当使用变量而非写死安装目录，以便于在不完全符合 FHS 的系统上安装，提高程序的可移植性。对于使用何种变量， GUN 提出了适用于 unix 系统的 GNU标准安装目录，GNU/Linux 上使用的就是这套标准的变体。cmake 官方提供了 GNUInstallDirs 模块，定义了一组标准的变量，用于安装不同类型文件到规范指定的目录中。

要使用这个模块，在 CMakeLists.txt 添加一行 include(GNUInstallDirs) 即可导入。如果你发现 CMAKE_INSTALL_XXXX 的值为空，大概率是缺少这一行。注意导入模块需要放在使用变量之前。

前缀值 CMAKE_INSTALL_PREFIX

CMAKE_INSTALL_PREFIX（后面简称 PREFIX）是一个非常特殊的变量，在 CMakeLists.txt 中所有的相对路径都会默认把 PREFIX 作为前缀进行拼接，组成绝对路径。这一变量是 cmake 基础变量，不导入 GNUInstallDirs 模块也会存在。

举一个例子，假如之前要把文件安装进 /usr/share 目录

install(FILES ${QM_FILES} DESTINATION /usr/share/deepin-calculator/translations)

如果设置了 PREFIX=/usr，只需要改成相对路径 share，cmake 会自动拼接成 /usr/share

install(FILES ${QM_FILES} DESTINATION share/deepin-calculator/translations)

这样写，如果安装前缀改变，比如改成 /usr/local，只需要修改 CMAKE_INSTALL_PREFIX，而不用改 CMakeLists.txt 源码。

目前 CMAKE_INSTALL_PREFIX 按 GNU 的标准默认值是 /usr/local。而在 dde 的项目中，一般期望前缀值是 /usr。我们当然可以通过 cmake -DCMAKE_INSTALL_PREFIX=/usr 来修改 PREFIX，但最好在项目中添加下面 3 行修改一下 PREFIX 的默认值：

if (CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
 set(CMAKE_INSTALL_PREFIX /usr)
endif ()

这里容易犯两种错误：

没有检查 CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT 就直接 set：这会导致用户传入的参数失效，相当于硬编码了路径。
使用 if (NOT DEFINE CMAKE_INSTALL_PREFIX ) 判断用户是否传参了 PREFIX：实际上 PREFIX 无论什么情况都是有定义的，只能使用 CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT 判断是否是默认值。

对 CMAKE_INSTALL_PREFIX 的配置会对子目录生效，在 cmake 3.14 之前，先应用安装规则再处理 add_subdirectory，而 3.14 及后续版本，会按照声明的顺序运行所有安装规则/add_subdirectory，因此，除非你想给子目录单独配置，上述的设置应写在 add_subdirectory 的前面。见 CMP0082。

GNUInstallDirs 变量

在 GNUInstallDirs 中，定义了一些 GNU 标准安装目录的变量，提供给定类型文件的安装路径。这些值可以传递给对应 install() 命令的 DESTINATION 选项。它们通常是相对于安装前缀（PREFIX）的相对路径，以便于以可重定位的方式将其拼接为绝对路径。当然，它们也允许赋值为绝对路径。

CMAKE_INSTALL_XXXX

CMAKE_INSTALL_BINDIR 用户可执行程序（ bin ）
CMAKE_INSTALL_SBINDIR 系统管理员可执行程序（ sbin ）
CMAKE_INSTALL_LIBEXECDIR 可执行库文件（ libexec ）
CMAKE_INSTALL_SYSCONFDIR 单机只读数据/read-only single-machine data（ etc ）
CMAKE_INSTALL_SHAREDSTATEDIR 架构无关的可修改数据/modifiable architecture-independent data （ com ）
CMAKE_INSTALL_LOCALSTATEDIR 单机可修改数据/modifiable single-machine data（ var ）
CMAKE_INSTALL_RUNSTATEDIR 3.9版中加入：运行时可修改数据（ LOCALSTATEDIR/run ）
CMAKE_INSTALL_LIBDIR 目标代码库/object code libraries （ lib 或 lib64 ）（在 Debian 上当 PREFIX 是 /usr 时，LIBDIR 也可能是 lib/<multiarch-tuple> ）
CMAKE_INSTALL_INCLUDEDIR C语言头文件（ include ）
CMAKE_INSTALL_OLDINCLUDEDIR non-gcc 的C语言头文件（ /usr/include ）
CMAKE_INSTALL_DATAROOTDIR 与架构无关的只读数据根目录（ share ）
CMAKE_INSTALL_DATADIR 与架构无关的只读数据（ DATAROOTDIR ）
CMAKE_INSTALL_INFODIR info 文档（ DATAROOTDIR/info ）
CMAKE_INSTALL_LOCALEDIR 与语言相关的数据/locale-dependent data（ DATAROOTDIR/locale ）
CMAKE_INSTALL_MANDIR man 文档（ DATAROOTDIR/man ）
CMAKE_INSTALL_DOCDIR 文档根目录（ DATAROOTDIR/doc/PROJECT_NAME ）

需要注意的是 DATAROOTDIR 是 DATADIR，LOCALEDIR，MANDIR 和 DOCDIR 共同前缀，不应该在 install 中直接使用 DATAROOTDIR 作为参数，而是应该使用 DATADIR 代替。类似 /usr/share/man 的路径应该用 MANDIR 代替，而不是 DATADIR/man。

CMAKE_INSTALL_FULL_XXXX

CMAKE_INSTALL_BINDIR 推荐用相对路径，但也可以使用绝对路径，有些时候我们需要绝对路径（比如生成 pkgconfig 文件时），直接加 PREFIX 拼接并不好（因为 BINDIR 可能已经是绝对路径了），这时，我们可以直接使用 CMAKE_INSTALL_FULL_BINDIR，这是由 GNUInstallDirs 模块提供，自动从 BINDIR 计算出的绝对路径。如果 BINDIR 是绝对路径，直接相等。如果 BINDIR 是相对路径，则等于 BINDIR 按照一定规则与 PREFIX 拼接而成的值。

用例： https://github.com/linuxdeepin/dde-dock/pull/556

当然，install 是没有必要用 CMAKE_INSTALL_FULL_XXXX 的（当然用也可以），因为它会自动判断，并拼接相对路径。

前缀拼接的特殊情况

GNUInstallDirs 前缀拼接存在一些特殊情况需要注意：

1. CMAKE_INSTALL_PREFIX=/

除了 SYSCONFDIR, LOCALSTATEDIR 和 RUNSTATEDIR 正常拼接外, 其他值都会增加一个 usr/ 前缀。比如 INCLUDEDIR 默认值 include ，变成 usr/include, 最终拼接成 /usr/include。

这里自动增加 usr 是符合 GNU 目录标准的，因为这些路径是符号链接。
~ ❯❯❯ readlink /lib
usr/lib
~ ❯❯❯ readlink /bin
usr/bin

2. CMAKE_INSTALL_PREFIX=/usr

SYSCONFDIR, LOCALSTATEDIR 和 RUNSTATEDIR 拼接时只拼接 “/”。比如, SYSCONFDIR 默认值 etc 会拼接成 /etc。

3. CMAKE_INSTALL_PREFIX=/opt/…

SYSCONFDIR, LOCALSTATEDIR 和 RUNSTATEDIR 会向后拼接。比如， SYSCONFDIR 会变成 /etc/opt/….

参考文档

DDE-Control-Center 自启动管理插件成果展示

dde 自启动管理插件开发小组博客 — Sun, 14 Aug 2022 06:00:00 +0000

DDE 控制中心自启动管理插件可单独编译、集成至 DDE 控制中心、集中展示并管理Deepin系统中软件开机自启动设置。

参赛信息

本项目参加2023全国大学生计算机系统能力大赛操作系统设计赛-功能挑战赛，选题为proj223-control-center-startup-management-plugin。

参赛小组：

复旦大学朱元依
复旦大学沈扬
复旦大学朱俊杰

指导老师：

复旦大学张亮
复旦大学陈辰
企业导师王子冲

完成情况

1、DDE 控制中心自启动管理插件

任务	完成情况
（必须）完成一个控制中心插件，能够展示当前所有开机启动项的列表	完成
（必须）插件以单独的仓库提供，并能够单独构建，不需要合并入 dde-control-center 项目	完成
（必须）能够在插件中，通过用户界面的交互来管理（添加、删除、启用、禁用）开机启动项	完成
（必须）编写博客，记录开发过程的心得与体会，并将博客投递至 planet.deepin.org	完成博客编写，待deepin官方审核

成果展示

功能展示视频链接：

链接：https://pan.baidu.com/s/1YgvhbZ8pypE4CFhuBYw3eg 提取码：rwcc

插件图标：

自启动管理窗口：

添加自启动应用选择界面：

部署方式

1、系统环境

开发环境：Deepin V23Beta版

系统架构：x86

镜像下载链接：https://mirrors.ustc.edu.cn/deepin-cd/releases/23-Beta/

虚拟机平台：WMware Workstation 16Pro

操作系统环境搭建参考博客：https://blog.csdn.net/qq_44133136/article/details/105887560

2、配置 Deepin 插件环境

安装依赖包：

sudo apt build-dep .
sudo apt install -y qt5-default
sudo apt-get install dde-control-center-dev

3、安装插件

sudo sh install.sh

安装成功后，打开控制中心，会看到以下自启动插件图标，即为安装成功：

此时，如果进入/usr/lib/x86_64-linux-gnu/dde-control-center/modules/文件夹，看到编译出的.so文件已经被下载到该文件夹中：

4、卸载插件

sudo sh uninstall.sh

重启控制中心，可以看到原本的“自启动管理”图标消失，即为卸载成功。

分工

朱元依：插件前端开发

沈扬：环境配置，编写配置文件

朱俊杰：后端接口开发（添加、删除、启用、禁用）

开发计划

第一步（6/26～7/8）

调研DDE Control Center框架等相关内容
设计前端界面
分工

第二步（7/9～7/15）

编译教程中的Hello World控制中心插件
设计插件架构

第三步（7/16～7/22）

配置环境，编译V20示例插件
设计后端接口
修改window、operation、category下的文件

第四步（7/23～7/29）

配置环境，编译Default-App与Self Start-up插件
Debug

第五步（7/30～8/10）

修改翻译、文字颜色问题
撰写文档

REUSE使用指南

deepin 社区官方博客 — Wed, 10 Aug 2022 13:00:00 +0000

什么是REUSE

REUSE是一个工具，准确的来说是一个帮助我们下载开源许可证书和检查开源声明是否合规的脚本：

使用REUSE配置项目

安装

REUSE依赖于本地的python环境，所以需要首先安装python和pip

sudo apt install python3
curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
sudo python3 get-pip.py

然后安装REUSE

pip3 install --user reuse

在此之后，确保它~/.local/bin在您的$PATH中。在 Windows 上，您的环境所需的路径可能类似于 %USERPROFILE%\AppData\Roaming\Python\Python39\Scripts，具体取决于您安装的 Python 版本。

使用

初始化项目

如果你在这一步遗漏了也没事，可以使用reuse download <许可证名称>的方式下载所需的许可证，这些许可证会一并放入项目下的License文件夹中

为代码文件添加版权声明

使用自动化脚本添加

reuse addheader --copyright="UnionTech Software Technology Co., Ltd." --license=GPL-3.0-or-later -r <目录>

这只是一个简单的例子，本质上resuse还有更多的用法：

--copyright-style可以将默认值更改 SPDX-FileCopyrightText为以下样式之一：

spdx: SPDX-FileCopyrightText: <year> <statement>
spdx-symbol: SPDX-FileCopyrightText: © <year> <statement>
string: Copyright <year> <statement>
string-c: Copyright (C) <year> <statement>
string-symbol: Copyright © <year> <statement>
symbol: © <year> <statement>

reuse不会限制你使用多少个copyright 也不会限制你使用的license的个数。

reuse 会猜测你使用的语言，并且添加对应的注释格式，如果不能正确添加或者需要更多的需求可以考虑下面的方法。

手动进行添加

自动进行添加

为非代码文件添加版权声明

在项目中是存在非代码文件，比如图片，音频等等。部分也是受到版权保护的，但是我们也没法直接在上面操作（别和我说水印和音频水印，这俩玩意不能无损添加）所以我们要使用一个外置的dep5文件去声明这些非代码文件的版权，dep5文件在执行项目init之后就已经自动帮你生成好了，所以直接写就是的了。比如：

# css
Files: *.css
Copyright: None
License: CC0-1.0

第一行就是注释，第二行是适合的文件，第三行是版权信息（如果使用cc0,则填写None），第四行是使用的licence。第一行的注释你可以选择不写，但是为了以后的可读性，强烈建议你写上，甚至可以作为分类的标签。

第二行文件，支持使用通配符进行模糊匹配，但是不支持正则表达式：仅支持，*匹配任意多个字符 ？匹配一个字符。所以可以利用通配符来制定匹配某一个文件夹下面的所有文件

例子：

# assets
Files: styleplugins/dstyleplugin/assets/*
Copyright: UnionTech Software Technology Co., Ltd.
License: GPL-3.0-or-later

这个例子展示了有版权信息的情况

例子：

# png svg
Files: platformthemeplugin/icons/* styleplugins/chameleon/menu_shadow.svg styles/images/woodbackground.png
styles/images/woodbutton.png tests/iconengines/builtinengine/icons/actions/icon_Layout_16px.svg
tests/iconengines/svgiconengine/icon_window_16px.svg
Copyright: None
License: CC0-1.0

这个例子展示了为多个文件路径及文件配置版权信息

强烈推荐你使用路径和具体文件名的方式来制定版权信息，而要避免大范围使用通配符的情况

例子：

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: qt5integration
Upstream-Contact: UnionTech Software Technology Co., Ltd. <>
Source: https://github.com/linuxdeepin/qt5integration
# README
Files: README.md CHANGELOG.md
Copyright: None
License: CC0-1.0
# assets
Files: styleplugins/dstyleplugin/assets/*
Copyright: UnionTech Software Technology Co., Ltd.
License: GPL-3.0-or-later
# Project file
Files: *.pro *.prf *.pri
Copyright: None
License: CC0-1.0
# css
Files: *.css
Copyright: None
License: CC0-1.0
# qrc
Files: *.qrc
Copyright: None
License: CC0-1.0
# png svg
Files: platformthemeplugin/icons/* styleplugins/chameleon/menu_shadow.svg styles/images/woodbackground.png
styles/images/woodbutton.png tests/iconengines/builtinengine/icons/actions/icon_Layout_16px.svg
tests/iconengines/svgiconengine/icon_window_16px.svg
Copyright: None
License: CC0-1.0
# sh
Files: tests/test-recoverage-qmake.sh
Copyright: None
License: CC0-1.0
# ignore git
Files: .git*
Copyright: None
License: CC0-1.0
# xml toml json conf yaml
Files: *.xml *.toml *.json *conf *.yaml
Copyright: None
License: CC0-1.0
# rpm
Files: rpm/*
Copyright: None
License: CC0-1.0
# debian
Files: debian/*
Copyright: None
License: CC0-1.0
# Arch
Files: archlinux/*
Copyright: None
License: CC0-1.0

无需版权声明文件的处理方案

.gitignore 是用来忽略某些与项目无关的文件和编译过程中产生的文件，同样的如果reuse也会忽略在.gitignore中标记的文件
dep5 在执行项目init之后，会在项目目录下产生.reuse/dep5 文件，打开后能看到官方给的范例，如果一个文件不需要特殊版权声明则使用CC0-1.0（会放弃对此文件的所有版权）

检查项目合规

reuse lint

这个命令会列出项目文件数，如果项目已经合规，将会以：-）提示，如果项目有些文件不符合开源许可证规范将会以：-（提示，此时你就需要按照上面的提示进行相应的修改即可。

一般情况下，每个文件都需要有与之相关的版权和许可信息。REUSE规范详细说明了几种方法。总的来说，有这些方法：

将标签放在文件的标题中。
将标签放置在与.license文件相邻的文件中。
将信息放入 DEP5 文件中。

如果发现一个文件没有与之关联的版权和/或许可信息，则该项目不合规。

个人建议

个人建议如果对现有项目使用reuse配置且需要保留版权的时间信息，不要使用一键配置版权头的方式，而是进行手动替换，这里推荐使用vscode的文件筛选功能，筛选出你需要添加的文件，然后cv下去。在配置dep5文件的时候，一定小心通配符的范围，不宜过大。并且对于第三方版权文件一定得小心规避，同样需要完整保留第三方版权信息。

统信软件常见Dep5书写参考

参考详细见：

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: dtkgui
Upstream-Contact: UnionTech Software Technology Co., Ltd. <>
Source: https://github.com/linuxdeepin/dtkgui
# ci
Files: .github/* .gitlab-ci.yml
Copyright: None
License: CC0-1.0
# gitignore #
Files: .gitignore
Copyright: None
License: CC0-1.0
# json conf yaml
Files: *.json *conf *.yaml
Copyright: None
License: CC0-1.0
#interface
Files: src/util/D* src/kernel/D* src/filedrag/D*
Copyright: None
License: CC0-1.0
# rpm
Files: rpm/*
Copyright: None
License: CC0-1.0
# debian
Files: debian/*
Copyright: None
License: LGPL-3.0-or-later
# Arch
Files: archlinux/*
Copyright: None
License: CC0-1.0
# README&doc
Files: README.md doc/src/*.qdoc
Copyright: None
License: CC-BY-4.0
# DBus
Files: src/dbus/*.xml
Copyright: None
License: CC0-1.0
# Project file
Files: *.pro *.prf *.pri *.qrc *CMakeLists.txt
Copyright: None
License: CC0-1.0
# svg
Files: src/util/icons/actions/* src/util/icons/icons/* src/util/icons/texts/*
tests/images/logo_icon.svg
Copyright: UnionTech Software Technology Co., Ltd.
License: LGPL-3.0-or-later

常见开源协议选择

lambda

deepin 社区官方博客 — Sat, 09 Jul 2022 18:23:58 +0000

这里整理一些关于c++中的匿名函数的知识.

《C++ primer》上有的内容就不在重述了.这里重点讲一些primer上可能没有的东西.

捕获的时机

primer 向我们介绍到: 有两种捕获变量的方式, 值捕获和引用捕获. 其中:

…

与参数不同,被捕获的变量的值是在lambda创建时拷贝,而不是调用时拷贝

…

如果我们采用引用方式捕获一个变量,就必须确保被引用的对象在lambda执行的时候是存在的.lambda捕获的都是局部变量,这些变量在函数结束后就不复存在了.

…

我们看一段代码:

auto funtionTimesMod1(int mod) {
int variableA = mod;
auto f = [variableA](int a, int b) { return a % variableA * b % variableA; };
return f;
}
void test1() {
cout << "---test1---" << endl;
int a = 10, b = 20, c = 7;
auto times = funtionTimesMod1(c);
cout << times(a, b) << endl;
}

这里funtionTimesMod1(int mod)返回一个签名为int(int, int)的函数,这个函数计算两个参数相乘对mod取模的结果.

当然可以正常运行,结果为4,如果我们将它换成引用捕获:

auto funtionTimesMod2(int mod) {
int variableA = mod;
auto f = [&variableA](int a, int b) { return a % variableA * b % variableA; };
return f;
}
void test2() {
cout << "---test2---" << endl;
int a = 10, b = 20, c = 7;
auto times = funtionTimesMod2(c);
cout << times(a, b) << endl;
}

这段代码就已经不能正常工作了,它的输出是 0.

我们来看看为啥:

Process 15820 stopped
* thread #1, name = 'tmp', stop reason = step in
frame #0: 0x000000000040096b tmp`funtionTimesMod2(mod=7) at tmp.cpp:17
14 }
15
16 auto funtionTimesMod2(int mod) {
-> 17 int variableA = mod;
18 auto f = [&variableA](int a, int b) { return a % variableA * b % variableA; };
19 return f;
20 }
(lldb) p &variableA
(int *) $1 = 0x00007fffffffe120
Process 15820 stopped
* thread #1, name = 'tmp', stop reason = step over
frame #0: 0x00000000004009dc tmp`test2() at tmp.cpp:25
22 cout << "---test2---" << endl;
23 int a = 10, b = 20, c = 7;
24 auto times = funtionTimesMod2(c);
-> 25 cout << times(a, b) << endl;
26 }
27 auto funtionTimesMod3(int mod) {
28 int variableA = mod;
(lldb) p times
((anonymous class)) $2 = {
variableA = 0x00007fffffffe120
}

可以看到times这个对象中保存下来的variableA只是一个指针,它指向我们之前创建的局部变量variableA,这个地址在栈上,这意味着当我们真的调用times的时候,局部变量variableA所在的那片内存已经被使用过了.所以会返回错误的结果.接下来,我们可以看到实际上调用的时候variableA里面是20,这是因为刚好参数b被放置在了variableA之前的位置上.

Process 21271 stopped
* thread #1, name = 'tmp', stop reason = step in
frame #0: 0x0000000000400a32 tmp`funtionTimesMod2(this=0x00007fffffffe158, a=10, b=20)::$_1::operator()(int, int) const at tmp.cpp:18
15
16 auto funtionTimesMod2(int mod) {
17 int variableA = mod;
-> 18 auto f = [&variableA](int a, int b) { return a % variableA * b % variableA; };
19 return f;
20 }
21 void test2() {
(lldb) p variableA
(int) $3 = 20
(lldb) p &b
(int *) $4 = 0x00007fffffffe120

lambda 的实现

根据《C++ Primer》在10.3以及14.8.1的介绍,我们知道一个lambda表达式是由编译器负责翻译成一个没有类名,重载过调用运算符的对象的.

这解释了为什么我们只能用auto来定义一个lambda类型的变量,因为这个类是没有名字的, 或者说它的名字是编译器自己生成的,我们并不能知道它叫什么.

这听起来很美好,我们也确实可以写出代码,用一个自己创建的,重载过调用运算符的对象,来模拟一个lambda:

class INT {
public:
int num;
INT(const INT &i) : num(i.num) { cout << "Copy constructor" << endl; }
INT() = default;
};
auto funtionTimesMod3(int mod) {
INT variableA;
cout << "----A" << endl;
variableA.num = mod;
cout << "----B" << endl;
auto f = [variableA](int a, int b) {
cout << "----C" << endl;
return a % variableA.num * b % variableA.num;
};
cout << "----D" << endl;
return f;
}
void test3() {
cout << "---test3---" << endl;
int a = 10, b = 20, c = 7;
cout << "----E" << endl;
auto times = funtionTimesMod3(c);
cout << "----F" << endl;
cout << times(a, b) << endl;
cout << "----G" << endl;
}
auto funtionTimesMod4(int mod) {
INT variableA;
cout << "----A" << endl;
variableA.num = mod;
cout << "----B" << endl;
class function {
const INT variableA;
public:
function(const INT &variableA) : variableA(variableA) {}
int operator()(int a, int b) {
cout << "----C" << endl;
return a % variableA.num * b % variableA.num;
}
} f(variableA);
cout << "----D" << endl;
return f;
}
void test4() {
cout << "---test4---" << endl;
int a = 10, b = 20, c = 7;
cout << "----E" << endl;
auto times = funtionTimesMod4(c);
cout << "----F" << endl;
cout << times(a, b) << endl;
cout << "----G" << endl;
}

为了观察发生的值拷贝的时机,以确定我们自己写的这个类的行为和lambda真的完全一致,我们可以自定义一个class,并且让他发生拷贝构造的时候打印一些信息.

运行结果如下:

---test3---
----E
----A
----B
Copy constructor
----D
----F
----C
4
----G
---test4---
----E
----A
----B
Copy constructor
----D
----F
----C
4
----G

这又一次说明了说明捕获引起的值拷贝发生在lambda被初始化的时候.

看起来这两个东西的行为几乎一致, 但是真的是这样吗?

编译器的优化

编译器会对我们写的代码做出一些优化,以减少复制对象的次数.如果不了解这点可以看看这篇博客.

如果我们关闭返回值优化,那么运行的结果是这样的:

---test3---
----E
----A
----B
Copy constructor
Copy constructor
----D
Copy constructor
Copy constructor
----F
----C
4
----G
---test4---
----E
----A
----B
Copy constructor
----D
Copy constructor
Copy constructor
----F
----C
4
----G

可以看到我们自己写的类,少了一次拷贝构造.

我们先来解释一下lambda为什么会发生这么多次拷贝构造.

auto funtionTimesMod3(int mod) {
INT variableA; // 5
 cout << "----A" << endl; // 6
 variableA.num = mod; // 7
 cout << "----B" << endl; // 8
 auto f = [variableA](int a, int b) {
cout << "----C" << endl; // 14
 return a % variableA.num * b % variableA.num; //15
 }; // 9
 cout << "----D" << endl; // 10
 return f; // 11
}
void test3() {
cout << "---test3---" << endl; // 1
 int a = 10, b = 20, c = 7; // 2
 cout << "----E" << endl; // 3
 auto times = funtionTimesMod3(c); // 4
 cout << "----F" << endl; // 12
 cout << times(a, b) << endl; // 13
 cout << "----G" << endl; //16
}

首先我们的程序是按照如上的顺序运行的.

可以看到前两个拷贝构造发生在9,而第3、4次发生在11.

如果完全按照语义来看的话,9这句话可以有两种理解方式:

创建一个lambda对象,对象名字叫f,这个对象的内容就是后面那个lambda表达式.
创建一个lambda表达式,然后将其作为参数,调用同类型对象f的拷贝构造函数.

如果按照第一种方法来理解,那么第9行发生两次拷贝构造就不是很能理解了.

所以应该是第二种.

在10之后也发生了两次拷贝调用.应该是先建立了一个变量用来做返回值,比如说叫r,然后将f赋值给返回值变量r,然后返回值变量r在被赋值给test3()中的times,这样发生的两次拷贝构造.

auto funtionTimesMod4(int mod) {
INT variableA;
cout << "----A" << endl;
variableA.num = mod;
cout << "----B" << endl;
class function {
const INT variableA;
public:
function(const INT &variableA) : variableA(variableA) {}
int operator()(int a, int b) {
cout << "----C" << endl;
return a % variableA.num * b % variableA.num;
}
} f(variableA); // <- 这里
 cout << "----D" << endl;
return f;
}
void test4() {
cout << "---test4---" << endl;
int a = 10, b = 20, c = 7;
cout << "----E" << endl;
auto times = funtionTimesMod4(c);
cout << "----F" << endl;
cout << times(a, b) << endl;
cout << "----G" << endl;
}

之前自己模拟lambda的这个代码,我们在注释标注的那个位置的实现和lambda中,“先建一个右值,然后拷贝构造出f"的行为不太一样.导致这里少了一次拷贝构造.所以实际上应该是这样:

auto funtionTimesMod5(int mod) {
INT variableA;
cout << "----A" << endl;
variableA.num = mod;
cout << "----B" << endl;
class function {
const INT variableA;
public:
function(const INT &variableA) : variableA(variableA) {}
int operator()(int a, int b) {
cout << "----C" << endl;
return a % variableA.num * b % variableA.num;
}
};
function f = function(variableA);
cout << "----D" << endl;
return f;
}
void test5() {
cout << "---test5---" << endl;
int a = 10, b = 20, c = 7;
cout << "----E" << endl;
auto times = funtionTimesMod5(c);
cout << "----F" << endl;
cout << times(a, b) << endl;
cout << "----G" << endl;
}

实际上没必要纠结那么多,正常编译的话,其实是不会去先建一个右值的对象的.

代码

#include <bits/stdc++.h>
using namespace std;
auto funtionTimesMod1(int mod) {
int variableA = mod;
auto f = [variableA](int a, int b) { return a % variableA * b % variableA; };
return f;
}
void test1() {
cout << "---test1---" << endl;
int a = 10, b = 20, c = 7;
auto times = funtionTimesMod1(c);
cout << times(a, b) << endl;
}
auto funtionTimesMod2(int mod) {
int variableA = mod;
auto f = [&variableA](int a, int b) { return a % variableA * b % variableA; };
return f;
}
void test2() {
cout << "---test2---" << endl;
int a = 10, b = 20, c = 7;
auto times = funtionTimesMod2(c);
cout << times(a, b) << endl;
}
class INT {
public:
int num;
INT(const INT &i) : num(i.num) { cout << "Copy constructor" << endl; }
INT() = default;
};
auto funtionTimesMod3(int mod) {
INT variableA;
cout << "----A" << endl;
variableA.num = mod;
cout << "----B" << endl;
auto f = [variableA](int a, int b) {
cout << "----C" << endl;
return a % variableA.num * b % variableA.num;
};
cout << "----D" << endl;
return f;
}
void test3() {
cout << "---test3---" << endl;
int a = 10, b = 20, c = 7;
cout << "----E" << endl;
auto times = funtionTimesMod3(c);
cout << "----F" << endl;
cout << times(a, b) << endl;
cout << "----G" << endl;
}
auto funtionTimesMod4(int mod) {
INT variableA;
cout << "----A" << endl;
variableA.num = mod;
cout << "----B" << endl;
class function {
const INT variableA;
public:
function(const INT &variableA) : variableA(variableA) {}
int operator()(int a, int b) {
cout << "----C" << endl;
return a % variableA.num * b % variableA.num;
}
} f(variableA);
cout << "----D" << endl;
return f;
}
void test4() {
cout << "---test4---" << endl;
int a = 10, b = 20, c = 7;
cout << "----E" << endl;
auto times = funtionTimesMod4(c);
cout << "----F" << endl;
cout << times(a, b) << endl;
cout << "----G" << endl;
}
auto funtionTimesMod5(int mod) {
INT variableA;
cout << "----A" << endl;
variableA.num = mod;
cout << "----B" << endl;
class function {
const INT variableA;
public:
function(const INT &variableA) : variableA(variableA) {}
int operator()(int a, int b) {
cout << "----C" << endl;
return a % variableA.num * b % variableA.num;
}
};
function f = function(variableA);
cout << "----D" << endl;
return f;
}
void test5() {
cout << "---test5---" << endl;
int a = 10, b = 20, c = 7;
cout << "----E" << endl;
auto times = funtionTimesMod5(c);
cout << "----F" << endl;
cout << times(a, b) << endl;
cout << "----G" << endl;
}
int main() {
test1();
test2();
test3();
test4();
test5();
}

使用 Bcache 对机械硬盘加速

myml — Sat, 18 Jun 2022 16:09:58 +0000

Bcache 是 Linux 下的一个块缓存内核模块，可用于使用单个固态硬盘为一个或多个机械硬盘加速，也可用于使用本地磁盘为网络磁盘的加速。

Bcache 有比较灵活的缓存模式，支持安全读写缓存(writethrough)、高性能读写缓存(writeback)、只读缓存(writearound)、停用缓存(none)等模式，并且可在线动态调整。

Bcache 还会自动识别顺序写入，当发现正在进行顺序写入时跳过缓存层，以减少缓存设备(固态硬盘)的损耗，延长固态硬盘的寿命。

DDE-Dock 自启动管理插件成果展示

dde 自启动管理插件开发小组博客 — Mon, 30 May 2022 06:00:00 +0000

DDE 自启动管理插件可用于集中管理Deepin系统中软件开机自启动设置的插件。

项目链接：DDE 自启动管理插件 github仓库

参赛信息

本项目参加2023全国大学生计算机系统能力大赛操作系统设计赛-功能挑战赛，选题为proj223-control-center-startup-management-plugin。

参赛小组：

复旦大学朱元依
复旦大学沈扬
复旦大学朱俊杰

指导老师：

复旦大学张亮
复旦大学陈辰
企业导师王子冲

完成情况

项目文档位于根目录的初赛报告.md。
博客地址：https://y-aang.github.io （题目：DDE 自启动管理插件）

任务	完成情况
（必须）完成一个控制中心插件，能够展示当前所有开机启动项的列表	完成
（必须）插件以单独的仓库提供，并能够单独构建，不需要合并入 dde-control-center 项目	完成
（必须）能够在插件中，通过用户界面的交互来管理（添加、删除、启用、禁用）开机启动项	完成
（必须）编写博客，记录开发过程的心得与体会，并将博客投递至 planet.deepin.org	完成博客编写，待deepin官方审核

成果展示

功能展示视频链接：

链接：百度网盘链接

提取码：hoo8

插件图标：

自启动管理窗口：

部署方式

1、系统环境

开发环境：Deepin 20Beta版

系统架构：x86

镜像下载链接：Deepin 操作系统下载链接

虚拟机平台：WMware Workstation 16Pro

操作系统环境搭建参考博客：环境搭建博客

2、安装依赖库

安装包 build-essential、git、g++、cmake、dde、dtk

sudo apt install build-essential git g++ cmake
sudo apt install dde-dock-dev libdtkwidget-dev

3、安装插件

克隆该仓库，进入文件夹后以sudo权限运行install.sh脚本

git clone https://github.com/PinappleUnderTheSea/os223.git
cd os233
sudo su
sh install.sh

出现成果展示章节的图标，即为安装成功。

提交仓库目录和文件描述

分工

朱元依：插件类框架开发、部件类前端开发

沈扬：自启动管理功能逻辑设计、插件类右键功能开发

朱俊杰：自启动管理窗口后端接口开发（添加、删除、启用、禁用）

开发计划

第一步（4/9～4/18）

调研Deepin、dde-dock、QT框架等相关内容
设计项目方案
分工

第二步（4/19～5/2）

搭建主体插件类的框架
设计启动项管理窗口的前端展示页面

第三步（5/3～5/13）

开发部件类接口
完善插件类功能

第四步（5/14～5/21）

插件类右键功能开发
完成配置文件

第五步（5/22～5/31）

Debug
撰写文档

使用 if constexpr 实现条件编译

deepin 社区官方博客 — Thu, 10 Mar 2022 13:03:27 +0000

在项目开发中，我们通常会使用条件编译对代码进行裁剪，选择性地排除不需要的代码，比如在某个平台下完全不支持某个功能，那么这个功能就不应该被编译。

一般我们使用宏来判断代码，选择性的挑选需要编译的部分，并在构建系统中开启这样的条件。

#ifdef XXXXXXXXXX
 std::cout << "hello world!" << std::endl;
#else
 std::cout << "good bye!" << std::endl;
#endif

在 C 语言的项目中，这样的行为是很正常的，甚至在 C++ 项目中，我们也会选择使用宏进行条件判断。

但是如果定义的宏多了，则很容易导致代码碎片化，并且无法直观地看到工作流程。

例如这样的代码:

#define KWIN_VERSION_CHECK(major, minor, patch, build) ((major<<24)|(minor<<16)|(patch<<8)|build)
#ifdef KWIN_VERSION_STR
#define KWIN_VERSION KWIN_VERSION_CHECK(KWIN_VERSION_MAJ, KWIN_VERSION_MIN, KWIN_VERSION_PAT, KWIN_VERSION_BUI)
#endif

#if defined(KWIN_VERSION) && KWIN_VERSION < KWIN_VERSION_CHECK(5, 21, 3, 0)
typedef int TimeArgType;
#else
typedef std::chrono::milliseconds TimeArgType;
#endif

#if defined(Q_OS_LINUX) && !defined(QT_NO_DYNAMIC_LIBRARY) && !defined(QT_NO_LIBRARY)
QT_BEGIN_NAMESPACE
QFunctionPointer qt_linux_find_symbol_sys(const char *symbol);
QT_END_NAMESPACE
QFunctionPointer KWinUtils::resolve(const char *symbol)
{
return QT_PREPEND_NAMESPACE(qt_linux_find_symbol_sys)(symbol);
#else
QFunctionPointer KWinUtils::resolve(const char *symbol)
{
static QString lib_name = "kwin.so." + qApp->applicationVersion();
return QLibrary::resolve(lib_name, symbol);
#endif
}

从上面的例子中可以看到，代码中一旦出现大量重复的判断条件，代码非常不直观，而且被宏分割成了很多部分。

在一次偶然的机会，我看到了一篇介绍 C++ 17 中的 if constexpr 的用法，可以在编译期进行一些计算，虽然我很早就知道了 constexpr 的用法，但是大家举的例子基本上都是数值计算，让编译器在编译期间将数值进行计算，从而减轻运行时的消耗，我也从来想到其他用法，所以一直没有在项目中使用到。

constexpr 的作用并不是编译期计算数值，而是编译期进行的代码分析，如果代码较小且非常直观，比如大家经常举的例子，在编译期间计算斐波那契数列，这种例子即使不使用 constexpr 显式要求，编译器也会帮助我们开启优化，直接给出结果。

但是如果代码非常复杂，编译器就不一定会为我们做这样的优化，就需要我们手动标记可以计算的位置，要求编译器在编译期间进行求值和优化。

我设想的是，使用 cmake 在构建时，先生成一份文件，将开关的值记录下来，在需要进行判断的地方，就可以直接使用 if constexpr 进行条件判断，在编译期间，编译器会发现有一个分支确定不会被执行（相当于 if(false) {}），那么这个分支就不会进行编译，直接剔除。

CMakeLists.txt 中需要做一些工作，将编译参数加入构建系统。

option (ENABLE_MODULE "Enable Module" ON)

if(ENABLE_MODULE)
 set(ENABLE_MODULE "1")
else()
 set(ENABLE_MODULE "0")
endif(ENABLE_MODULE)

configure_file (
"${CMAKE_CURRENT_SOURCE_DIR}/options/options.h.in"
"${CMAKE_CURRENT_BINARY_DIR}/options/options.h"
)

在 options/options.h.in 文件里，按照 cmake 的要求将变量导入进文件中，进行内容替换。

#pragma once

#cmakedefine01 ENABLE_MODULE

这里我仍然使用的是宏定义，也可以直接写成如下形式:

option (ENABLE_MODULE "Enable Module" ON)

if(ENABLE_MODULE)
 set(ENABLE_MODULE "true")
else()
 set(ENABLE_MODULE "false")
endif(ENABLE_MODULE)

configure_file (
"${CMAKE_CURRENT_SOURCE_DIR}/options/options.h.in"
"${CMAKE_CURRENT_BINARY_DIR}/options/options.h"
)

#pragma once

const bool ENABLE_MODULE{@ENABLE_MODULE@};

在 main.cpp 中写一段测试代码:

#include "options/options.h"

#include <iostream>

int main() {
if constexpr (ENABLE_MODULE) {
std::cout << "Now Enable Module" << std::endl;
}
if constexpr (!ENABLE_MODULE) {
std::cout << "Now Disable Module" << std::endl;
}
return 0;
}

执行结果是符合预期的。

# lxz @ lxz-MacBook-Pro in ~/Develop/constexpr-demo/build on git:master o [13:28:39]
$ cmake ../ -G Ninja -DENABLE_MODULE=ON
-- The CXX compiler identification is AppleClang 13.0.0.13000029
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/lxz/Develop/constexpr-demo/build
# lxz @ lxz-MacBook-Pro in ~/Develop/constexpr-demo/build on git:master o [13:28:45]
$ ninja
[2/2] Linking CXX executable src/constexpr
# lxz @ lxz-MacBook-Pro in ~/Develop/constexpr-demo/build on git:master o [13:28:48]
$ ./src/constexpr
Now Enable Module
# lxz @ lxz-MacBook-Pro in ~/Develop/constexpr-demo/build on git:master o [13:28:52]
$ cmake ../ -G Ninja -DENABLE_MODULE=OFF
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/lxz/Develop/constexpr-demo/build
# lxz @ lxz-MacBook-Pro in ~/Develop/constexpr-demo/build on git:master o [13:28:58]
$ ninja
[2/2] Linking CXX executable src/constexpr
# lxz @ lxz-MacBook-Pro in ~/Develop/constexpr-demo/build on git:master o [13:29:00]
$ ./src/constexpr
Now Disable Module

虽然结果是符合的，但是我们其实不确定是否真的在编译期间就完成了代码剔除，所以使用命令进行汇编，查看汇编中是否包含了判断指令和两段输出的字符串。

clang -S main.cpp -o main.s -I./

main.s

 .text
.file "main.cpp"
.globl main // -- Begin function main
.p2align 2
.type main,@function
main: // @main
.cfi_startproc
// %bb.0:
stp x29, x30, [sp, #-32]! // 16-byte Folded Spill
str x19, [sp, #16] // 8-byte Folded Spill
mov x29, sp
.cfi_def_cfa w29, 32
.cfi_offset w19, -16
.cfi_offset w30, -24
.cfi_offset w29, -32
adrp x19, :got:_ZSt4cout
ldr x19, [x19, :got_lo12:_ZSt4cout]
adrp x1, .L.str
add x1, x1, :lo12:.L.str
mov w2, #18
mov x0, x19
bl _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l
ldr x8, [x19]
ldur x8, [x8, #-24]
add x8, x8, x19
ldr x19, [x8, #240]
cbz x19, .LBB0_5
// %bb.1:
ldrb w8, [x19, #56]
cbz w8, .LBB0_3
// %bb.2:
ldrb w1, [x19, #67]
b .LBB0_4
.LBB0_3:
mov x0, x19
bl _ZNKSt5ctypeIcE13_M_widen_initEv
ldr x8, [x19]
mov w1, #10
mov x0, x19
ldr x8, [x8, #48]
blr x8
mov w1, w0
.LBB0_4:
adrp x0, :got:_ZSt4cout
ldr x0, [x0, :got_lo12:_ZSt4cout]
bl _ZNSo3putEc
bl _ZNSo5flushEv
ldr x19, [sp, #16] // 8-byte Folded Reload
mov w0, wzr
ldp x29, x30, [sp], #32 // 16-byte Folded Reload
ret
.LBB0_5:
bl _ZSt16__throw_bad_castv
.Lfunc_end0:
.size main, .Lfunc_end0-main
.cfi_endproc
// -- End function
.section .text.startup,"ax",@progbits
.p2align 2 // -- Begin function _GLOBAL__sub_I_main.cpp
.type _GLOBAL__sub_I_main.cpp,@function
_GLOBAL__sub_I_main.cpp: // @_GLOBAL__sub_I_main.cpp
.cfi_startproc
// %bb.0:
stp x29, x30, [sp, #-32]! // 16-byte Folded Spill
str x19, [sp, #16] // 8-byte Folded Spill
mov x29, sp
.cfi_def_cfa w29, 32
.cfi_offset w19, -16
.cfi_offset w30, -24
.cfi_offset w29, -32
adrp x19, _ZStL8__ioinit
add x19, x19, :lo12:_ZStL8__ioinit
mov x0, x19
bl _ZNSt8ios_base4InitC1Ev
adrp x0, :got:_ZNSt8ios_base4InitD1Ev
ldr x0, [x0, :got_lo12:_ZNSt8ios_base4InitD1Ev]
mov x1, x19
ldr x19, [sp, #16] // 8-byte Folded Reload
adrp x2, __dso_handle
add x2, x2, :lo12:__dso_handle
ldp x29, x30, [sp], #32 // 16-byte Folded Reload
b __cxa_atexit
.Lfunc_end1:
.size _GLOBAL__sub_I_main.cpp, .Lfunc_end1-_GLOBAL__sub_I_main.cpp
.cfi_endproc
// -- End function
.type _ZStL8__ioinit,@object // @_ZStL8__ioinit
.local _ZStL8__ioinit
.comm _ZStL8__ioinit,1,1
.hidden __dso_handle
.type .L.str,@object // @.str
.section .rodata.str1.1,"aMS",@progbits,1
.L.str:
.asciz "Now Disable Module" // 关键在这里
.size .L.str, 19
.section .init_array,"aw",@init_array
.p2align 3
.xword _GLOBAL__sub_I_main.cpp
.ident "clang version 13.0.1"
.section ".note.GNU-stack","",@progbits
.addrsig
.addrsig_sym _GLOBAL__sub_I_main.cpp
.addrsig_sym _ZStL8__ioinit
.addrsig_sym __dso_handle
.addrsig_sym _ZSt4cout

查看整个 main.s 汇编，发现只在 .L.str 段中有预期的文本字符串，可以得出结论，代码是在编译期间完成了剔除，符合我们的要求。

原文链接：https://blog.justforlxz.com/2022/03/10/if-constexpr/

QDir 和 std::filesystem 的简单对比

deepin 社区官方博客 — Fri, 04 Mar 2022 10:11:45 +0000

作为一名使用 Qt 的开发人员，Qt 为我提供了大量好用的基础设施，例如广受好评的 QString、QNetwork之类的，这是 Qt 平台为我提供的帮助，我只需要在这个平台上开发就足够了。

同样作为一名 C++ 开发人员，C++ 标准库也是我需要用的基础设施，但是标准库提供的功能就不如 Qt 了，最令人诟病的就是 C++ 的 std::string，业内充斥着对 std::string 的不屑与谩骂。

但是这一情况将会在 C++ 20 标准后改善，这里不具体展开，将来我会准备写一份 C++ 20 的功能介绍。

今天在开发项目的时候，为了节省资源，我仅使用标准库完成开发，缺少了 Qt 平台为我提供的有利帮助，项目开发的难度瞬间增加，在此期间，我发现了 C++ 的目录操作似乎能比的上 Qt 提供的 QDir封装，我打算在本篇文章中介绍一下这两者的不同。

QDir

Qt 的基本思路是继承大于组合，所以 Qt 为我们提供的都是各种继承的类，在 Qt 中，我们使用 QDir 类进行目录操作。

QDir 类使用相对或绝对文件路径来指向一个文件或目录。如果总是使用 “/” 作为目录分隔符，Qt 将会把你的路径转化为符合底层的操作系统的。

QDir 类由于不涉及 IO 的具体操作，所以没有继承自 QObject 或者其他 QIO 的类。

QDir 提供了非常多的方法，可以方便的获取目录的名称、绝对路径、相对路径、设置目录过滤器等。

一个基本的用法如下:

QDir dir("/tmp");
if (!dir.exists()) {
return
}
for (const QFileInfo& item : dir.entryInfoList()) {
if (item.isDir()) {
// ...
}
}
dir.setFilter(QDir::Files | QDir::Hidden | QDir::NoSymLinks);
dir.setSorting(QDir::Size | QDir::Reversed);
const QFileInfoList& list = dir.entryInfoList();
for (const QFileInfo& item : list) {
// ...
}

在上面的示例代码中可以看到，QDir 整体是非常符合面向对象的，我们使用 QDir 对象，对目录执行各种操作，涉及到具体的文件（目录是特殊的文件），我们可以使用 QFileInfo 类获取具体文件的信息。

除了以上演示涉及到的方法，QDir 还有很多其他方法，使用 count() 方法统计目录内文件和目录的数量，使用 remove() 方法删除指定的目录，这里就不一一列举了。

QDir 支持设置多种过滤，过滤(Filter) 和排序(Sorting) 都会影响到 entryInfoList 方法返回的内容。

QDir 接受的过滤器枚举:

枚举	枚举值	描述
QDir::Dirs	0x001	列出与过滤器匹配的目录。
QDir::AllDirs	0x400	列出所有目录；即不要将过滤器应用于目录名称。
QDir::Files	0x002	列出文件。
QDir::Drives	0x004	列出磁盘驱动器（在Unix下忽略）。
QDir::NoSymLinks	0x008	不要列出符号链接（不支持符号链接的操作系统忽略）。
QDir::NoDotAndDotDot	NoDot	NoDotDot
QDir::NoDot	0x2000	不要列出特殊条目“.”。
QDir::NoDotDot	0x4000	不要列出特殊条目“..”。
QDir::AllEntries	Dirs	Files
QDir::Readable	0x010	列出应用程序具有读取访问权限的文件。可读值需要与Dirs或Files合并。
QDir::Writable	0x020	列出应用程序具有写入访问权限的文件。可写值需要与Dirs或Files合并。
QDir::Executable	0x040	列出应用程序具有执行访问权限的文件。可执行值需要与Dirs或Files合并。
QDir::Modified	0x080	仅列出已修改的文件（在Unix上忽略）。
QDir::Hidden	0x100	列出隐藏的文件（在Unix上，以“.”开头的文件）。
QDir::System	0x200	列出系统文件（包括Unix、FIFO、套接字和设备文件；在Windows上，包括.lnk文件）
QDir::CaseSensitive	0x800	过滤器应该区分大小写。

QDir 接受的排序枚举:

枚举	枚举值	描述
QDir::Name	0x00	按名称排序。
QDir::Time	0x01	按时间（修改时间）排序。
QDir::Size	0x02	按文件大小排序。
QDir::Type	0x80	按文件类型（扩展名）排序。
QDir::Unsorted	0x03	不要排序。
QDir::NoSort	-1	默认情况下未排序。
QDir::DirsFirst	0x04	先放目录，然后放文件。
QDir::DirsLast	0x20	先放文件，然后放目录。
QDir::Reversed	0x08	颠倒排序顺序。
QDir::IgnoreCase	0x10	不区分大小写的排序。
QDir::LocaleAware	0x40	使用当前区域设置对项目进行适当排序。

std::filesystem

上面介绍了 Qt 的设计风格，而标准库的设计风格是组合大于继承，标准库提供各种非常具体的类或者函数，将一个系列的操作拆分为各个子项，最终完成任务。

这里使用一个小例子来说明一下:

std::filesystem::path tmp{"/tmp"};
if (!std::filesystem::exists(tmp)) {
std::cout << "目录不存在" << std::endl;
return;
}
const bool result = std::filesystem::create_directories(tmp);
if (!result) {
std::cout << "目录创建失败，也许是已经存在。" << std::endl;
}
for (auto const& dir_entry : std::filesystem::directory_iterator(tmp)) {
if (dir_entry.is_directory()) {
// ...
 }
}
if (std::filesystem::is_directory(tmp)) {
// ...
}

可以看到，C++ 标准库使用多个类共同完成了对目录的检查和遍历，这种基于组合的方式可以带来更多的灵活性，如果需要对某个部分进行修改，只需要继承特定类就可以完成，如果是 Qt 的 QDir，则不是很轻松。

在使用标准库的时候需要注意的是，标准库通常不会约束使用者，使用当前的例子举例，QDir 提供了过滤器枚举，可以帮助开发者简单的实现文件过滤功能，但是 std::filesystem 则不提供这种接口，标准库提供了机制，但是不提供策略，开发者需要使用标准库提供的各种接口，组合出自己的业务，所以如果想要使用标准库的时候也能实现过滤和排序，就只能自己提供相应的操作。

std::filesystem::path tmp{ "/tmp" };
std::vector<std::filesystem::directory_entry> list;
std::vector<std::string> filter{ ".jpg", ".txt" };
std::filesystem::directory_iterator iter{ tmp };
std::copy_if(iter.begin(),
iter.end(),
std::back_inserter(list),
[filter](std::filesystem::directory_entry entry) {
return !entry.is_directory() &&
std::find_if(filter.begin(),
filter.end(),
[entry](std::string s) {
return entry.path().extension() == s;
}
);
}
);

~~可以看到，代码变得异常丑陋（逃~~

标准库提供了一些比较方便的函数，例如 std::copy_if、 std::back_inserter 和 std::find_if 等，还有一个较为常用的 std::transform。标准库提供了迭代器抽象，这样我们可以使用迭代器对象和迭代器算法，方便的进行各种遍历、复制和转换。

从上面的例子可以看出，Qt 确实为开发者提供了很好的帮助，这是 Qt 作为一个平台力所能及的工作，当然，即使我们使用 Qt，也还是可以写出上面一样的代码。

总结

以上就是简单的 QDir 和 std::filesystem 的不同，综合来看，Qt 库和标准库其实各有优缺，他们的目标和面向的开发者是不同的，Qt 最近一直在尝试使用标准库的内容来代替自己的一部分组件，最新的Qt6 就已经升级到了 C++ 17 标准，将 qSort 宏改为了使用 std::sort，也许在不久的将来，我们再也不用为使用 Qt 还是标准库而争论或者站队。

引用资料 std::filesystem https://en.cppreference.com/w/cpp/filesystem QDir https://doc.qt.io/qt-5/qdir.html

原文链接：https://blog.justforlxz.com/2022/03/04/qdir-stdfilesystem/

QDir 和 std::filesystem 的简单对比

justforlxz — Fri, 04 Mar 2022 02:11:45 +0000

但是这一情况将会在 C++ 20 标准后改善，这里不具体展开，将来我会准备写一份 C++ 20 的功能介绍。

QDir

Qt 的基本思路是继承大于组合，所以 Qt 为我们提供的都是各种继承的类，在 Qt 中，我们使用 QDir 类进行目录操作。

QDir 类使用相对或绝对文件路径来指向一个文件或目录。如果总是使用 “/” 作为目录分隔符，Qt 将会把你的路径转化为符合底层的操作系统的。

QDir 类由于不涉及 IO 的具体操作，所以没有继承自 QObject 或者其他 QIO 的类。

QDir 提供了非常多的方法，可以方便的获取目录的名称、绝对路径、相对路径、设置目录过滤器等。

一个基本的用法如下:

QDir dir("/tmp");
if (!dir.exists()) {
 return
}

for (const QFileInfo& item : dir.entryInfoList()) {
 if (item.isDir()) {
 // ...
 }
}

dir.setFilter(QDir::Files | QDir::Hidden | QDir::NoSymLinks);
dir.setSorting(QDir::Size | QDir::Reversed);

const QFileInfoList& list = dir.entryInfoList();
for (const QFileInfo& item : list) {
 // ...
}

QDir 支持设置多种过滤，过滤(Filter) 和排序(Sorting) 都会影响到 entryInfoList 方法返回的内容。

QDir 接受的过滤器枚举:

枚举	枚举值	描述
QDir::Dirs	0x001	列出与过滤器匹配的目录。
QDir::AllDirs	0x400	列出所有目录；即不要将过滤器应用于目录名称。
QDir::Files	0x002	列出文件。
QDir::Drives	0x004	列出磁盘驱动器（在Unix下忽略）。
QDir::NoSymLinks	0x008	不要列出符号链接（不支持符号链接的操作系统忽略）。
QDir::NoDotAndDotDot	NoDot	NoDotDot
QDir::NoDot	0x2000	不要列出特殊条目“.”。
QDir::NoDotDot	0x4000	不要列出特殊条目“..”。
QDir::AllEntries	Dirs	Files
QDir::Readable	0x010	列出应用程序具有读取访问权限的文件。可读值需要与Dirs或Files合并。
QDir::Writable	0x020	列出应用程序具有写入访问权限的文件。可写值需要与Dirs或Files合并。
QDir::Executable	0x040	列出应用程序具有执行访问权限的文件。可执行值需要与Dirs或Files合并。
QDir::Modified	0x080	仅列出已修改的文件（在Unix上忽略）。
QDir::Hidden	0x100	列出隐藏的文件（在Unix上，以“.”开头的文件）。
QDir::System	0x200	列出系统文件（包括Unix、FIFO、套接字和设备文件；在Windows上，包括.lnk文件）
QDir::CaseSensitive	0x800	过滤器应该区分大小写。

QDir 接受的排序枚举:

枚举	枚举值	描述
QDir::Name	0x00	按名称排序。
QDir::Time	0x01	按时间（修改时间）排序。
QDir::Size	0x02	按文件大小排序。
QDir::Type	0x80	按文件类型（扩展名）排序。
QDir::Unsorted	0x03	不要排序。
QDir::NoSort	-1	默认情况下未排序。
QDir::DirsFirst	0x04	先放目录，然后放文件。
QDir::DirsLast	0x20	先放文件，然后放目录。
QDir::Reversed	0x08	颠倒排序顺序。
QDir::IgnoreCase	0x10	不区分大小写的排序。
QDir::LocaleAware	0x40	使用当前区域设置对项目进行适当排序。

std::filesystem

这里使用一个小例子来说明一下:

std::filesystem::path tmp{"/tmp"};
if (!std::filesystem::exists(tmp)) {
 std::cout << "目录不存在" << std::endl;
 return;
}

const bool result = std::filesystem::create_directories(tmp);
if (!result) {
 std::cout << "目录创建失败，也许是已经存在。" << std::endl;
}

for (auto const& dir_entry : std::filesystem::directory_iterator(tmp)) {
 if (dir_entry.is_directory()) {
 // ...
 }
}

if (std::filesystem::is_directory(tmp)) {
 // ...
}

std::filesystem::path tmp{ "/tmp" };
std::vector<std::filesystem::directory_entry> list;
std::vector<std::string> filter{ ".jpg", ".txt" };
std::filesystem::directory_iterator iter{ tmp };
std::copy_if(iter.begin(),
 iter.end(),
 std::back_inserter(list),
 [filter](std::filesystem::directory_entry entry) {
 return !entry.is_directory() && 
 std::find_if(filter.begin(),
 filter.end(),
 [entry](std::string s) {
 return entry.path().extension() == s;
 }
 );
 }
);

~~可以看到，代码变得异常丑陋（逃~~

总结

引用资料
std::filesystem https://en.cppreference.com/w/cpp/filesystem
QDir https://doc.qt.io/qt-5/qdir.html

翻译: Git from the bottom up | 自底向上聊 Git

deepin 社区官方博客 — Fri, 21 Jan 2022 09:40:08 +0000

这是一个 git from the bottom up 的中文翻译.

由于译者水平有限, 保留了英文, 防止误解.

如果真有人看, 还发现了什么错误, 欢迎提 issue, 欢迎 pr.

为了保持整个文章在一个文件里面所以我并没有单独保存图片文件, 引用了原文的图片链接, 只要原文不挂应该问题就不大.

This text is licensed under Creative Commons BY 4.0. Please see the text of that license here:

https://creativecommons.org/licenses/by/4.0/legalcode

0 Introduction | 介绍

Welcome to the world of Git. I hope this document will help to advance your understanding of this powerful content tracking system, and reveal a bit of the simplicity underlying it — however dizzying its array of options may seem from the outside.

欢迎来到 Git 的世界. 我希望这个文档可以加深读者对这一个内容跟踪系统的认识. 虽然 Git 的操作选项从使用者的角度看起来令人头晕眼花, 但是我希望借这篇文档展示它底层的简洁性.

Before we dive in, there are a few terms which should be mentioned first, since they’ll appear repeatedly throughout this text:

在我们进一步讨论之前, 有几个名词我们需要先做出一些解释, 之后我们将在这篇文章中不断地见到他们.

0.1 repository

repository — A repository is a collection of commits, each of which is an archive of what the project’s working tree looked like at a past date, whether on your machine or someone else’s. It also defines HEAD (see below), which identifies the branch or commit the current working tree stemmed from. Lastly, it contains a set of branches and tags, to identify certain commits by name.

repository — repository 是由若干 commit 组成的集合, 这些 commit 可以存在你的机器上, 也可以在其他的地方, 它们是 working tree 曾经状态的存档. repository 同时定义了 HEAD (下面有), 它标志着当前的 working tree 的来源. repository 还含有一个由 branch 和 tag 组成的集合, branch 和 tag 可以看作是某个 commit 的别名, 用户可以通过这个别名来找到某个 commit.

0.2 the index

the index — Unlike other, similar tools you may have used, Git does not commit changes directly from the working tree into the repository. Instead, changes are first registered in something called the index. Think of it as a way of “confirming” your changes, one by one, before doing a commit (which records all your approved changes at once). Some find it helpful to call it instead as the “staging area”, instead of the index.

the index — Git 并不像其他你使用过的类似工具那样直接把 working tree 中的更改直接 commit 到 repository 中, 而是先将 working tree 中的更改注册到一个叫 the index 的地方. 你可以把这看作是 Git 要求你在做一个 commit 之前, 对你的每个更改的再次确认, 这个 commit 将会一次性记录所有你再次确认过的更改. 有人认为与其叫它 the index 不如将其称作 staging area (暂存区).

0.3 working tree

working tree — A working tree is any directory on your filesystem which has a repository associated with it (typically indicated by the presence of a sub-directory within it named .git.). It includes all the files and sub-directories in that directory.

working tree — working tree 是在你的文件系统中任何一个与某个 repository 相关联的文件夹, 通常来说这样的文件夹都会有一个叫 .git 的子目录. 一个 working tree 包含了这样一个文件夹下所有的文件和子目录.

0.4 commit

commit — A commit is a snapshot of your working tree at some point in time. The state of HEAD (see below) at the time your commit is made becomes that commit’s parent. This is what creates the notion of a “revision history”.

commit — commit 是某个时间点上你的 working tree 的一个快照¹. 当你提交一个 commit 的时候, HEAD 指向的 commit 会成为你提交的 commit 的父 commit. 这个机制让我们得以追溯修改的历史.

0.5 branch

branch — A branch is just a name for a commit (and much more will be said about commits in a moment), also called a reference. It’s the parentage of a commit which defines its history, and thus the typical notion of a “branch of development”.

branch — branch 只是某个的 commit 的别名², 也可以认为是一个引用. 它是一个 commit 的来历, 记录着我们是如何到达这个 commit 的. 这很好地体现了分支开发的理念.

0.6 tag

tag — A tag is also a name for a commit, similar to a branch, except that it always names the same commit, and can have its own description text.

tag — tag 是另一种 commit 的别名, 和 branch 很类似, 除了它永远都是某个特定 commit 的别名, 以及一个 tag 可以有它自己的说明文字.

0.7 master

master — The mainline of development in most repositories is done on a branch called “master”. Although this is a typical default, it is in no way special.

master — 大部分主要的开发都在一个叫 “master” 的分支上完成, 这只是一个默认的名称, 并没有什么特殊的.

0.8 HEAD

HEAD — HEAD is used by your repository to define what is currently checked out:

If you checkout a branch, HEAD symbolically refers to that branch, indicating that the branch name should be updated after the next commit operation.

If you checkout a specific commit, HEAD refers to that commit only. This is referred to as a detached HEAD, and occurs, for example, if you check out a tag name.

HEAD — HEAD 是被你的 repository 用来确定什么东西是当前 checkout 的:
- 如果你 checkout 一个 branch, HEAD 就会指向那个 branch, 这意味着这个 branch 在下一次 commit 之后会更新.
- 如果你 checkout 某个特定的 commit, 那么 HEAD 只会指向那个 commit. 发生这种事情的时候, 我们称一个 HEAD 处在脱离的状态. 当你 checkout 一个 tag 的时候也会发生这样的事情.

The usual flow of events is this: After creating a repository, your work is done in the working tree. Once your work reaches a significant point — the completion of a bug, the end of the working day, a moment when everything compiles — you add your changes successively to the index. Once the index contains everything you intend to commit, you record its content in the repository. Here’s a simple diagram that shows a typical project’s life-cycle:

通常来说, 你用 Git 工作的流程是这样的: 在创建一个 repository 之后, 你在 working tree 中完成工作. 每当你完成了一个阶段的工作, 比方说修正了一个 bug, 或者下班了, 还有比如"终于能过编译了!",你就把所有的更改都一个一个添加到 the index 中. 当 the index 中包含了所有你想 commit 的内容, 你就将这个 commit 的内容加入到 repository 中.这里有一个简单的示意图,展示了一个项目通常的生命周期:

With this basic picture in mind, the following sections shall attempt to describe how each of these different entities is important to the operation of Git.

请将上述的内容记在心里, 接下来的几节我们将说明这些东西对 Git 的操作的重要性.

1 Repository

1.1 Repository: Directory content tracking | Repository: 目录内容跟踪

As mentioned above, what Git does is quite rudimentary: it maintains snapshots of a directory’s contents. Much of its internal design can be understood in terms of this basic task.

就像上面提到的一样, Git 实际上做的事情非常的基础: 只是在维护一个目录里的内容的快照. Git 的许多内部设计都可以从这个角度来理解.

The design of a Git repository in many ways mirrors the structure of a UNIX filesystem:

Git 的 repository 的设计很多时候都和 UNIX 的文件系统很相似:

A filesystem begins with a root directory, which typically consists of other directories, most of which have leaf nodes, or files, that contain data. Meta-data about these files’ contents is stored both in the directory (the names), and in the i-nodes that reference the contents of those files (their size, type, permissions, etc). Each i-node has a unique number that identifies the contents of its related file. And while you may have many directory entries pointing to a particular i-node (i.e., hard-links), it’s the i-node which “owns” the contents stored on your filesystem.

文件系统 是从根目录开始的, 通常它会包括其他的所有目录. 大部分的目录会含有叶子节点或者说是文件 , 文件中才真正含有数据. 关于文件内容的元数据同时被存放在目录里, 以及引用这个文件的内容的那个 i-node 里. 在目录里只存了个文件名, 而在 i-node 中存放着文件的大小, 类型, 权限等等. 每个 i-node 有一个唯一的编码, 用于区分它关联的文件内容, 但是要注意: 是可能会出现多个文件目录指向了同一个 i-node 的情况的(比如说硬链接). 总的来说,是 i-node 最终管理着你存在文件系统里的数据文件.

Internally, Git shares a strikingly similar structure, albeit with one or two key differences.

从内部逻辑的角度来看, Git 除了一两处关键的不同之处以外, 与这个结构有着惊人的相似.

First, it represents your file’s contents in blobs, which are also leaf nodes in something awfully close to a directory, called a tree. Just as an i-node is uniquely identified by a system-assigned number, a blob is named by computing the SHA1 hash id of its size and contents.

首先, Git 将你的文件内容以 blob 的方式呈现. 而 blob 也是一个和目录十分类似的树形结构中的叶子节点, 这里我们直接将这种树形结构称为 tree. 和 i-node 有一个系统赋予的, 独一无二的值一样, 一个 blob 也有一个独一无二的标识符, 而这个标识符也就是这个 blob 的名字是从它的大小和内容运用 SHA1 哈希算法计算得出的.

For all intents and purposes this is just an arbitrary number, like an i-node, except that it has two additional properties:

这个值具体是什么并不重要, 在 Git 中我们基本上就是需要一个值来唯一地确定一个 blob, 这一点上和 i-node 很类似. 但是这个通过 SHA1 计算出来的哈希值却有两个额外的性质:

first, it verifies the blob’s contents will never change; and second, the same contents shall always be represented by the same blob, no matter where it appears: across commits, across repositories — even across the whole Internet. If multiple trees reference the same blob, this is just like hard-linking: the blob will not disappear from your repository as long as there is at least one link remaining to it.

首先, 这个值能够保证一个 blob 的内容不会被随意更改; 其次, 只要 blob 的内容一样, 他们总会有同一个标识符, 即使他们在不同的地方也一样: 在不同的 commit 之间相同内容的 blob 会有同一个名字, 不同仓库间的 blob 也一样, 即使是网络上的其他地方的 blob 也一样. 如果有多个 tree 引用了同一个 blob, 这情况几乎就和硬链接没什么两样: 直到没有 tree 引用这个 blob 了, 它才会从你的 repository 中消失.

The difference between a Git blob and a filesystem’s file is that a blob stores no metadata about its content. All such information is kept in the tree that holds the blob. One tree may know those contents as a file named “foo” that was created in August 2004, while another tree may know the same contents as a file named “bar” that was created five years later.

Git 中的 blob 和文件系统中的文件的一大区别就是 blob 中并没有存储与其内容相关的元数据. 这些信息是存放在引用这个 blob 的 tree 中的. 某个 tree 也许会觉得这个 blob 中的内容是一个叫 “foo” 的, 于 2004 年八月创建的文件, 同时另一个 tree 却会认为同样的一个 blob 对应着名叫 “bar” 的, 五年后才被创建的文件.

In a normal filesystem, two files with the same contents but with such different metadata would always be represented as two independent files. Why this difference? Mainly, it’s because a filesystem is designed to support files that change, whereas Git is not. The fact that data is immutable in the Git repository is what makes all of this work and so a different design was needed. And as it turns out, this design allows for much more compact storage, since all objects having identical content can be shared, no matter where they are.

通常来说, 在文件系统中, 两个内容一样却有不一样的元数据的文件总是会被当作是两个独立的文件. 为什么会有这种不同呢? 基本上我们可以认为这是因为文件系统主要是为了会变化的文件设计的, 而 Git 并不是, 我们反而是希望在 Git 中被存下来的快照不会发生变化的. 实际上这种设计甚至可以用来压缩存储空间, 因为它允许两个有相同内容的文件共享空间³.

1.2 Introducing the blob | 关于 blob 的二三事

Now that the basic picture has been painted, let’s get into some practical examples. I’m going to start by creating a sample Git repository, and showing how Git works from the bottom up in that repository. Feel free to follow along as you read:

我们已经大致了解了 Git 的工作原理, 现在让我们看一些实践中的案例. 我将创建一个 Git repository 作为例子, 用它来自底向上地展示 Git 是如何工作的. 你完全可以在阅读的同时也自己动手试试:

$ mkdir sample; cd sample
$ echo 'Hello, world!' > greeting

Here I’ve created a new filesystem directory named “sample” which contains a file whose contents are prosaically predictable. I haven’t even created a repository yet, but already I can start using some of Git’s commands to understand what it’s going to do. First of all, I’d like to know which hash id Git is going to store my greeting text under:

这里我创建了一个叫叫 “sample” 的文件夹, 它的内容是显而易见的. 目前我还没有创建一个 repository, 但是我实际上已经可以使用一些 Git 命令来简单解释一下接下来我们要干些啥. 首先, 我想知道一下这个叫 greeting 的文件被使用 Git 进行版本管理之后, 它对应的那个 blob 的名字是啥:

$ git hash-object greeting
af5626b4a114abcb82d63db7c8082c3c4756e51b

If you run this command on your system, you’ll get the same hash id. Even though we’re creating two different repositories (possibly a world apart, even) our greeting blob in those two repositories will have the same hash id. I could even pull commits from your repository into mine, and Git would realize that we’re tracking the same content — and so would only store one copy of it! Pretty cool.

如果你也在你的机子上跑了这条命令,你一定会和我得到一个同样的哈希值. 虽然我们甚至可能不在同一个位面⁴, 在两个不同的 repository 中, 同样的内容还是有同样的哈希值. 我甚至可以从你的 repository 中 pull 一些 commit 到我这里来, 如果我真的那么做了, Git 也会认识到我们两个人是在跟踪同样的一个内容 — 所以它也只会存储一份数据. 这真的很棒!

The next step is to initialize a new repository and commit the file into it. I ’m going to do this all in one step right now, but then come back and do it again in stages so you can see what’s going on underneath:

接下来我们创建一个新的 repository 然后把文件 commit 进去. 我接下来将一次性完成它, 之后我会再一步步的做一次, 这样有利于你理解到底发生了什么:

$ git init
$ git add greeting
$ git commit -m "Added my greeting"

At this point our blob should be in the system exactly as we expected, using the hash id determined above. As a convenience, Git requires only as many digits of the hash id as are necessary to uniquely identify it within the repository. Usually just six or seven digits is enough:

此时, 我们的那个 blob 应该正如我们预想的那样出现在这个系统中了, 它的哈希值正如上面所说的那样, 应该是af5626b4a114abcb82d63db7c8082c3c4756e51b. 方便起见, 只要你给出足以在这个 repository 中唯一确定这个 blob 的哈希值前缀, Git 就可以找到这样一个 blob. 通常来说六七个字符就够了:

$ git cat-file -t af5626b
blob
$ git cat-file blob af5626b
Hello, world!

There it is! I haven’t even looked at which commit holds it, or what tree it ’s in, but based solely on the contents I was able to assume it’s there, and there it is. It will always have this same identifier, no matter how long the repository lives or where the file within it is stored. These particular contents are now verifiably preserved, forever.

看, 我们已经找到他了, 我甚至都不需要知道是哪个 commit 引用了这个 blob, 也不用知道这个 blob 在哪个 tree 上, 我们只需要通过文件的内容就足以确定这个 blob 的存在. 这个文件一直都可以以这种方式来唯一确定, 不管这个repository存在了多久, 也不用管这个 blob 到底被存储在 repository 中的哪里. 这个内容已经被很好的保护了起来.

In this way, a Git blob represents the fundamental data unit in Git. Really, the whole system is about blob management.

Git 以这种方式在 repository 中呈现数据. 讲真, 整个 Git 都只是在管理 blob 而已.

1.3 Blobs are stored in trees | Blob 是存在 tree 里的

The contents of your files are stored in blobs, but those blobs are pretty featureless. They have no name, no structure — they’re just “blobs”, after all.

Git 在追踪文件的过程中, 将你文件里的内容存储在 blob 中, 但是 blob 的功能相当的有限, 它们没有文件名, 没有结构, 它们只是 “blob”, 仅此而已.

In order for Git to represent the structure and naming of your files, it attaches blobs as leaf nodes within a tree. Now, I can’t discover which tree(s) a blob lives in just by looking at it, since it may have many, many owners. But I know it must live somewhere within the tree held by the commit I just made:

为了能够记录下你文件的名字和结构, Git 将 blob 看作是 tree 的叶子节点来管理. 我们显然不能通过查看一个 blob 来看出它到底属于哪个 tree, 因为它很可能同时出现在相当多个 tree 中. 但是我知道它一定存在于哪个我们刚刚创建的 commit 所管理的 tree 中:

$ git ls-tree HEAD
100644 blob af5626b4a114abcb82d63db7c8082c3c4756e51b greeting

There it is! This first commit added my greeting file to the repository. This commit contains one Git tree, which has a single leaf: the greeting content’s blob.

这就是那个 blob 了! 这是我刚提交的那个, 将我的 greeting 文件添加到 repository 中的 commit. 这个 commit 里面有一个 Git tree, 而这个 tree 中只有一个叶子节点 — 那就是存放着 greeting 文件内容的那个 blob.

Although I can look at the tree containing my blob by passing HEAD to ls-tree, I haven’t yet seen the underlying tree object referenced by that commit. Here are a few other commands to highlight that difference and thus discover my tree:

尽管我可以通过向 ls-tree 这个命令传入 HEAD 来查看那个含有我的 blob 的 tree, 但是我还没从底层看到过那个被 commit 引用的 tree 对象. 这里有几个命令能说明这两者有什么不同⁵, 我们来看看:

$ git rev-parse HEAD
588483b99a46342501d99e3f10630cfc1219ea32 # different on your system
$ git cat-file -t HEAD
commit
$ git cat-file commit HEAD
tree 0563f77d884e4f79ce95117e2d686d7d6e282887
author John Wiegley <johnw@newartisans.com> 1209512110 -0400
committer John Wiegley <johnw@newartisans.com> 1209512110 -0400
Added my greeting

The first command decodes the HEAD alias into the commit it references, the second verifies its type, while the third command shows the hash id of the tree held by that commit, as well as the other information stored in the commit object. The hash id for the commit is unique to my repository — because it includes my name and the date when I made the commit — but the hash id for the tree should be common between your example and mine, containing as it does the same blob under the same name.

第一个命令通过 HEAD 找到它所指向的那个 commit, 第二个可以指明 HEAD 指针的类型, 而第三个命令则展示了那个 commit 所管理的 tree 的哈希值, 以及这个 commit 的一些相关信息. 这个 commit 的哈希值和你的系统中得到的是不同的, 因为如你所见, 一个 commit 中式包含作者和提交时间,还有说明文字等信息的, 这些东西都会加入哈希值的计算, 所以一定是不同的. 然而 tree 的哈希值却和你的系统中是一样的. 因为我们两的系统中, 这个 tree 的内容是完全一致的.

Let’s verify that this is indeed the same tree object:

我们来确认一下这个 tree 是真的和你那边相同:

$ git ls-tree 0563f77
100644 blob af5626b4a114abcb82d63db7c8082c3c4756e51b greeting

There you have it: my repository contains a single commit, which references a tree that holds a blob — the blob containing the contents I want to record. There’s one more command I can run to verify that this is indeed the case:

这里你可以看到, 我的 repository 中只包含一个 commit, 这个 commit 它关联到一个 tree, 而这个 tree 管理了一个 blob, 这个 blob 里面是我希望记录下来的内容. 还有一个命令也能展示这个情况:

$ find .git/objects -type f | sort
.git/objects/05/63f77d884e4f79ce95117e2d686d7d6e282887
.git/objects/58/8483b99a46342501d99e3f10630cfc1219ea32
.git/objects/af/5626b4a114abcb82d63db7c8082c3c4756e51b

From this output I see that the whole of my repo contains three objects, each of whose hash id has appeared in the preceding examples. Let’s take one last look at the types of these objects, just to satisfy curiosity:

在这个命令的输出中可以看到我的整个 repository 中只有三个对象, 每一个的哈希值你都已经见到过了. 为了满足好奇心, 我们甚至可以看一下他们对应的类型:

$ git cat-file -t 588483b99a46342501d99e3f10630cfc1219ea32
commit
$ git cat-file -t 0563f77d884e4f79ce95117e2d686d7d6e282887
tree
$ git cat-file -t af5626b4a114abcb82d63db7c8082c3c4756e51b
blob

I could have used the show command at this point to view the concise contents of each of these objects, but I’ll leave that as an exercise to the reader.

我本可以使用 show 命令来查看这些对象的内容, 但是我选择将这个留作读者的练习.

1.4 How trees are made | Tree 是怎样炼成的

Every commit holds a single tree, but how are trees made? We know that blobs are created by stuffing the contents of your files into blobs — and that trees own blobs — but we haven’t yet seen how the tree that holds the blob is made, or how that tree gets linked to its parent commit.

每个 commit 对应一个 tree, 但是 tree 是怎样炼成的呢? 我们已经知道了 blob 是基于你的文件内容创建的数据块, 以及 Git 是用 tree 来管理 blob 的. 但是我们还并不理解这些管理 blob 用的 tree 是如何被创建的, 或者说我们并不懂 tree 是如何连接到它的父 commit 的.

Let’s start with a new sample repository again, but this time by doing things manually, so you can get a feeling for exactly what’s happening under the hood:

我们来看上一节中提到的那个例子, 不过这次我们一步一步手动地做这些事情, 这样你可以明白底层到底发生了什么:

$ rm -fr greeting .git
$ echo 'Hello, world!' > greeting
$ git init
$ git add greeting

It all starts when you first add a file to the index. For now, let’s just say that the index is what you use to initially create blobs out of files. When I added the file greeting, a change occurred in my repository. I can’t see this change as a commit yet, but here is one way I can tell what happened:

这一切是从你首次将一个文件加入 the index 开始的. 现在让我们先这么认为: the index 是你初次用来将文件内容装填进 blob 时所需要使用的工具.当我添加名为 greeting 的文件时, 我的 repository 发生了一次修改, 而我目前还不能够将这个更改看作是 commit, 但是我还是有一个方法能够搞清到底发生了什么:

$ git log # this will fail, there are no commits!
fatal: bad default revision 'HEAD'
$ git ls-files --stage # list blob referenced by the index
100644 af5626b4a114abcb82d63db7c8082c3c4756e51b 0 greeting

What’s this? I haven’t committed anything to the repository yet, but already an object has come into being. It has the same hash id I started this whole business with, so I know it represents the contents of my greeting file. I could use cat-file -t at this point on the hash id, and I’d see that it was a blob. It is, in fact, the same blob I got the first time I created this sample repository. The same file will always result in the same blob (just in case I haven’t stressed that enough).

那么这是啥呢? 我还没有 commit 过任何东西啊? 但是实际上已经有一个东西在上述的操作中被生成了出来. 它的哈希值和我们一开始对 greeting 算出来的那个是一样的, 所以我们可以知道这个东西它里面是文件 greeting 的数据. 此时, 我可以使用命令 cat-file-t 来查看那个哈希值对应的文件, 实际上我们也看过了, 这个文件本身是一个 blob. 实际上它和我们一开始创建的那个 repository 中的那个 blob 是完全一样的东西.

This blob isn’t referenced by a tree yet, nor are there any commits. At the moment it is only referenced from a file named .git/index, which references the blobs and trees that make up the current index. So now let’s make a tree in the repo for our blob to hang off of:

这个 blob 目前还没有被某个 tree 引用, 实际上也没有被任何一个 commit 引用. 在这个时候, 实际上只有一个叫 .git/index的文件引用了这个 blob, 这文件里面引用了所有构成了当前的 index 的 blob 和 tree. 那么我们现在用这个 blob 来创建一个 tree:

$ git write-tree # record the contents of the index in a tree
0563f77d884e4f79ce95117e2d686d7d6e282887

This number should look familiar as well: a tree containing the same blobs (and sub-trees) will always have the same hash id. I don’t have a commit object yet, but now there is a tree object in that repository which holds the blob. The purpose of the low-level write-tree command is to take whatever the contents of the index are and tuck them into a new tree for the purpose of creating a commit.

这个值也令人十分熟悉: 两个包含同样的 blob, 或者说 sub-tree 们的 tree 的哈希值总时一样的. 我的 repository 中到现在还没有一个 commit, 但是已经有一个 tree 了, 这个 tree 还引用了一个 blob. wirte-tree 这个底层命令的存在, 使得我们可以将任何在 the index 中的内容装载到一个新的 tree 中, 然后用来创建一个 commit.

I can manually make a new commit object by using this tree directly, which is just what the commit-tree command does:

只需要用 commit-tree 命令, 我现在就可以用上面创建的 tree 来手动地创建一个新的 commit 对象, 就像这样:

$ echo "Initial commit" | git commit-tree 0563f77
5f1bc85745dcccce6121494fdd37658cb4ad441f

The raw commit-tree command takes a tree’s hash id and makes a commit object to hold it. If I had wanted the commit to have a parent, I would have had to specify the parent commit’s hash id explicitly using the -p option. Also, note here that the hash id differs from what will appear on your system: This is because my commit object refers to both my name, and the date at which I created the commit, and these two details will always be different from yours.

这个 commit-tree 命令需要知道那个 tree 的哈希值, 然后创建一个 commit 来管理它. 如果我想要这个 commit 有一个父 commit, 那我需要使用 -p 参数指定父 commit 的哈希值. 以及我们可以注意到, 这个 tree 的哈希值和你的系统上的是不同的, 这是因为我的 commit 中实际上包含了我的名字信息, 以及我创建这个 commit 的日期, 这两个值是和你的仓库中的情况不同的.

Our work is not done yet, though, since I haven’t registered the commit as the new head of a branch:

活还没完, 我们还没更新这个 commit 对应的分支:

$ echo 5f1bc85745dcccce6121494fdd37658cb4ad441f > .git/refs/heads/master

This command tells Git that the branch name “master” should now refer to our recent commit. Another, much safer way to do this is by using the command update-ref:

这个命令告诉 Git 该用 “master” 这个名字指代我们新提交的那个 commit 了. 还有一点要说的就是, 完成上面这件事情还有一个更安全的方法, 那就是使用 update-ref 命令:

$ git update-ref refs/heads/master 5f1bc857

After creating master, we must associate our working tree with it. Normally this happens for you whenever you check out a branch:

在创建⁶完 master 之后,我们必须将我们的 working tree 调整成和 master 相匹配的样子. 一般来说, 这个操作是用于 check out 一个分支的:

$ git symbolic-ref HEAD refs/heads/master

This command associates HEAD symbolically with the master branch. This is significant because any future commits from the working tree will now automatically update the value of refs/heads/master.

这个命令会将 HEAD 绑定到 master 分支上. 这一点是相当自然的, 因为我们接下来再从 working tree 中做出更改之后提交的 commit 应该要更新这个名叫 master 的分支, 也就是文件 refs/heads/master 的值.

It’s hard to believe it’s this simple, but yes, I can now use log to view my newly minted commit:

虽然很难相信, 但是 Git 的工作就是如此简单, 我还可以使用 log 命令来查看我刚一步步手动添加的这个 commit:

$ git log
commit 5f1bc85745dcccce6121494fdd37658cb4ad441f
Author: John Wiegley <johnw@newartisans.com>
Date: Mon Apr 14 11:14:58 2008 -0400
Initial commit

A side note: if I hadn’t set refs/heads/master to point to the new commit, it would have been considered “unreachable”, since nothing currently refers to it nor is it the parent of a reachable commit. When this is the case, the commit object will at some point be removed from the repository, along with its tree and all its blobs. (This happens automatically by a command called gc, which you rarely need to use manually). By linking the commit to a name within refs/heads, as we did above, it becomes a reachable commit, which ensures that it’s kept around from now on.

这里有个值得注意的地方: 如果我不曾将文件 refs/heads/master 指向那个新的 commit, 这个 commit 会被看作是 “不可达的”, 因为没有任何其他的东西和他有关联, 它也不是任何一个可达的 commit 的祖先. 当发生这种情况的时候, 这个 commit 将会被 Git 在某个时候从 repository 中移除, 它对应的 tree 和 blob 也一样, (这个事情会在运行一个叫 gc 的命令的时候自动地发生, 当然这个命令基本不会被用户手动运行). 如果我们像上面做的那样, 在目录 .git/heads 下用某个名字关联到这个 commit, 这个 commit 就是可达的了, 这可以保证它不会被删掉.

1.5 The beauty of commits | Commit 之美

Some version control systems make “branchCes” into magical things, often distinguishing them from the “main line” or “trunk”, while others discuss the concept as though it were very different from commits. But in Git there are no branches as separate entities: there are only blobs, trees and commits. Since a commit can have one or more parents, and those commits can have parents, this is what allows a single commit to be treated like a branch: because it knows the whole history that led up to it.

一些版本控制系统将 branch 弄得很晦涩难懂, 经常将 “主线” (或者说 “主干” ), 和 “分支” 区分开来, 而另一些版本控制系统则认为分支这个概念和 commit 有很大区别. 但是在 Git 中并没有 branch 这个实体: Git 里只有 blob, tree 以及 commit 这三个概念. 因为一个 commit 可以有多个父 commit 而这些父 commit 也有父亲, 所以我们实际上可以把单个 commit 当作 branch 来看待: 因为我们实际上可以从这个 commit 开始, 回溯出文件内容是如何一步步地被修改, 更迭到当前这个 commit 的这整个历史.

You can examine all the top-level, referenced commits at any time using the branch command:

你随时都可以通过 branch 命令查看所有顶层的, 被引用的 commit :

$ git branch -v
* master 5f1bc85 Initial commit

Say it with me: A branch is nothing more than a named reference to a commit. In this way, branches and tags are identical, with the sole exception that tags can have their own descriptions, just like the commits they reference. Branches are just names, but tags are descriptive, well, “tags”.

来跟着我一起念: “一个 branch 仅仅只是一个 commit 的引用, 只是这个引用本身还有一个名字罢了.” 从这种角度来看, branch 和 tags 几乎没有什么区别, 只有一个例外: tag 就像它指向的那个 commit 一样还可以拥有自己的说明性文字. branch 只是 commit 的名字, 但是 tag 是描述性的, 毕竟人家是 “标签” 嘛.

But the fact is, we don’t really need to use aliases at all. For example, if I wanted to, I could reference everything in the repository using only the hash ids of its commits. Here’s me being straight up loco and resetting the head of my working tree to a particular commit:

但是实际上我们也可以完全就不用这些别名. 比如说, 如果我想的话, 我实际上可以用 repository 中任何一个 commit 的哈希值来唯一地确定它. 下面这个是如果我想直接把我的 working tree 对应的 HEAD 指向某个特定的 commit 需要用的命令:

$ git reset --hard 5f1bc85

The –hard option says to erase all changes currently in my working tree, whether they’ve been registered for a checkin or not (more will be said about this command later). A safer way to do the same thing is by using checkout:

这个 --hard 选项的意思就是说, 让 Git 不管我当前的 working tree 中相对于给定的 commit 发生的所有更改是否有被记录下来过, 都把它们清除掉. 我们以后还会聊聊 reset 这个命令. 完成这件事情还有一个更安全的方式, 那就是使用 checkout 命令:

$ git checkout 5f1bc85

The difference here is that changed files in my working tree are preserved. If I pass the -f option to checkout, it acts the same in this case to reset --hard, except that checkout only ever changes the working tree, whereas reset --hard changes the current branch’s HEAD to reference the specified version of the tree.

这两者的区别在于, 后者对于我的 working tree 中的文件修改操作是有一定保护的, 对于没记录过的数据会做一次是否清除的询问. 如果我们将参数 -f 传递给 checkout命令, Git 的行为就会几乎和执行 reset --hard 时一模一样. 它们两之间的区别在于 checkout 命令只是清除 working tree 中的文件变化, 而 reset --hard 会将当前的 HEAD 指向的那个 branch 一起移动到某个版本的 tree 上.

Another joy of the commit-based system is that you can rephrase even the most complicated version control terminology using a single vocabulary. For example, if a commit has multiple parents, it’s a “merge commit” — since it merged multiple commits into one. Or, if a commit has multiple children, it represents the ancestor of a “branch”, etc. But really there is no difference between these things to Git: to it, the world is simply a collection of commit objects, each of which holds a tree that references other trees and blobs, which store your data. Anything more complicated than this is simply a device of nomenclature.

另一个使用基于 commit 的版本控制系统带来的乐趣是你可以用很简单的话语来描述版本控制系统中那些晦涩难懂的术语. 比方说, 如果一个 commit 拥有两个父 commit, 那么我们称这个 commit 是一个 “merge commit” — 因为它确实将多个 commit 合并了起来嘛.还有,如果一个 commit 拥有多个子 commit 这代表着这里是分支的开始, 诸如此类. 但是实际上这些术语所描述的事情对于 Git 来说并没有什么区别: 对于 Git 来说, 整个世界就是由 commit 对象组成的, 它们管理着一个 tree 而这个 tree 中又引用了其他的 tree 以及 blob, 在 blob 中实际存放着你的数据. 其他比这个复杂的东西都只是其他人对某个行为取的名字罢了.

Here is a picture of how all these pieces fit together:

这里有一张关于上面提到的种种对象之间的关系的图,也许可以帮助你的理解:

1.6 A commit by any other name… | Commit 的名字

Understanding commits is the key to grokking Git. You’ll know you have reached the Zen plateau of branching wisdom when your mind contains only commit topologies, leaving behind the confusion of branches, tags, local and remote repositories, etc. Hopefully such understanding will not require lopping off your arm — although I can appreciate if you’ve considered it by now.

对 commit 的理解对于弄懂 Git 来说非常关键. 当你抛弃了那些令人困惑的什么 branch, tag, 本地的以及远程 repository 之后, 当你的头脑中只剩下了 commit 相关的拓扑结构的时候, 你将会对 “分支” 的智慧有崭新的理解. 想过去这种对 commit 的理解对于你来不会是什么很困难的事情, 如果你现在就能开始试图理解 commit 我会很开心.

If commits are the key, how you name commits is the doorway to mastery. There are many, many ways to name commits, ranges of commits, and even some of the objects held by commits, which are accepted by most of the Git commands. Here ’s a summary of some of the more basic usages:

如果说 commit 是关键, 那么如何给 commit 命名就是理解 Git 的门道所在. 实际上有很多很多给 commit 命名的方式, 甚至连一次性给某个范围内的 commit 命名, 乃至于给一些由 commit 管理的对象命名, 都是可以办到的. 大部分的 Git 命令都支持这种操作. 这里有一些你需要知道的用法总结:

branchname — As has been said before, the name of any branch is simply an alias for the most recent commit on that “branch”. This is the same as using the word HEAD whenever that branch is checked out.

branchname — 就像之前说的那样, branch 的名字只是那个 “分支” 上最新的一个 commit 的别名. 这和你使用单词 HEAD 来表示当前 check out 的那个 branch 是一样的.

tagname — A tag-name alias is identical to a branch alias in terms of naming a commit. The major difference between the two is that tag aliases never change, whereas branch aliases change each time a new commit is checked in to that branch.

tagname — 从给 commit 命名的角度来看, 一个 tag 几乎和一个 branch 是一模一样的. 主要的区别在于 branch 指代的 commit 是可能会变化的, 它会在新的 commit 提交到这个 branch 的时候被更新成新的那个, 而 tag 不会.

HEAD — The currently checked out commit is always called HEAD. If you check out a specific commit — instead of a branch name — then HEAD refers to that commit only and not to any branch. Note that this case is somewhat special, and is called “using a detached HEAD” (I’m sure there’s a joke to be told here…).

HEAD — 当前 check out 的那个 commit 被称作 HEAD. 如果你 check out 了一个特定的 commit — 而不是一个 branch 的话 — 那么 HEAD 就只是指向了那个 commit 而已, 并没有指向任何一个 branch. 需要注意的是这是一种特殊的情况, 我们称这种情况为 HEAD 指针的脱离.

c82a22c39cbc32… — A commit may always be referenced using its full, 40-character SHA1 hash id. Usually this happens during cut-and-pasting, since there are typically other, more convenient ways to refer to the same commit.

c82a22c — You only need use as many digits of a hash id as are needed for a unique reference within the repository. Most of the time, six or seven digits is enough.

c82a22c39cbc32… — 我们总是可以通过一个 commit 的那个由四十个字符组成的 SHA1 哈希值来找到它. 通常这种事情发生在你需要复制粘贴的时候, 因为在其他情况下, 几乎都有更方便的方式来找到它.
c82a22c — 其实你只需要给出足够在当前的 repository 中唯一确定一个 commit 的哈希值的前缀就足以找到那个 commit 了, 一般来说是 6 到 7 位左右.

name^ — The parent of any commit is referenced using the caret symbol. If a commit has more than one parent, the first is used.

name^^ — Carets may be applied successively. This alias refers to “the parent of the parent” of the given commit name.

name^2 — If a commit has multiple parents (such as a merge commit), you can refer to the nth parent using name^n.

name~10 — A commit’s nth generation ancestor may be referenced using a tilde (~) followed by the ordinal number. This type of usage is common with rebase -i, for example, to mean “show me a bunch of recent commits”. This is the same as name^^^^^^^^^^.

name:path — To reference a certain file within a commit’s content tree, specify that file’s name after a colon. This is helpful with show, or to show the difference between two versions of a committed file:

接下来的几条中的 “name” 可以使用上文提到的所有可以找到 commit 的字符串替换, 以下是一些相对某个 commit 查询另一个 commit 的方法:

name^ — ^ 这个符号可以找到一个 commit 的父 commit, 如果这个 commit 有多个父 commit 那么查询的结果是第一个⁷.

name^^ — ^ 这个符号是可以被连续的调用的⁸, 这意味着你寻找的是当前 commit 的爷爷.

name^2 — 如果一个 commit 有多个父 commit — 比方说一个 merge commit — 那么如果你想找其中的第 n 个父 commit, 可以使用 name^n.
name~10 — 这意味着一个 commit 十代之前的那个祖宗, 第 n 代祖先,可以通过一个 ~ 符号后面跟着一个数字来找到. 这一般是用于执行 rebase -i 命令的时候用的. 效果和 name^^^^^^^^^^ 是完全一致的.
name:path — 你可以用这种方式来从一个 commit 中根据路径来找到 tree 中的某个特定文件. 一般来说这个功能在你想比较两个 commit 之间某个文件的差异的时候比较有用, 比如像下面这样:

 $ git diff HEAD^1:Makefile HEAD^2:Makefile

name^{tree} — You can reference just the tree held by a commit, rather than the commit itself.

name^{tree} — 上面说的都是找到某个 commit 的方法, 而你可以通过这个方式来指定一个 commit 管理的那个 tree.

name1..name2 — This and the following aliases indicate commit ranges, which are supremely useful with commands like log for seeing what’s happened during a particular span of time. The syntax to the left refers to all the commits reachable from name2 back to, but not including, name1. If either name1 or name2 is omitted, HEAD is used in its place.

name1…name2 — A “triple-dot” range is quite different from the two-dot version above. For commands like log, it refers to all the commits referenced by name1 or name2, but not by both. The result is then a list of all the unique commits in both branches. For commands like diff, the range expressed is between name2 and the common ancestor of name1 and name2. This differs from the log case in that changes introduced by name1 are not shown.

master.. — This usage is equivalent to “master..HEAD”. I’m adding it here, even though it’s been implied above, because I use this kind of alias constantly when reviewing changes made to the current branch.

..master — This, too, is especially useful after you’ve done a fetch and you want to see what changes have occurred since your last rebase or merge.

–since=“2 weeks ago” — Refers to all commits since a certain date.

–until=”1 week ago” — Refers to all commits before a certain date.

–grep=pattern — Refers to all commits whose commit message matches the regular expression pattern.

–committer=pattern — Refers to all commits whose committer matches the pattern.

–author=pattern — Refers to all commits whose author matches the pattern. The author of a commit is the one who created the changes it represents. For local development this is always the same as the committer, but when patches are being sent by e-mail, the author and the committer usually differ.

–no-merges — Refers to all commits in the range that have only one parent — that is, it ignores all merge commits.

以下都是一个范围内的 commit 的别名, 通常来说, 在调用 log 命令来查看过去的某段时间内, 代码到底发生了什么变化的时候非常的有用:

name1..name2 — 这意味着你选中了在树上遍历时, 从 name2 出发, 在遍历到 name1 之前所有可以遍历到的 commit, 当然是不包括 name1 的.如果你在 name1 或者 name2 的位置什么都没写, 那么意味着你希望在相应位置使用 HEAD 来代替 name1/name2.
- master.. — 这样可以选中 master 到 HEAD 的所有 commit, 一般来说, 在查看 dev 比 master 快了多少的时候比较有用.
- ..master — 这个通常用于: 在你完成了一次 fetch 之后, 想查看自己本地的 master 在上一次 rebase 或者是 merge 之后在远程仓库中被做了什么样的修改.
name1…name2 — 中间有三个点的范围和上面说的只有两个点的有很大的差异. 对于 log 这类的命令, 三个点的范围选中了所有被 name1 或者 name2 其中之一直接或者间接引用的所有 commit, 注意: 并不包括两者同时引用的 commit. 结果上来说, 这意味着你找到了一系这两个分支并不共同拥有的 commit. 而对于像 diff 这样的指令而言, 这样会选中从 name2 到 name1 和 name2 的最近公共祖先之间的所有 commit. differ 和 log 的区别实际上在于, 从 LCA 到 name1 这条路径上的 commit 并不会被选中.
–since=“2 weeks ago” — 这样可以选中某个特定日期之后的所有 commit.
–until=”1 week ago” — 与上一条类似, 选中某个特定日期之前的所有 commit.
–grep=pattern — 选中所有在 commit message 中有和 pattern 匹配的内容的 commit.
–committer=pattern — 选中所有提交者名字和 pattern 相匹配的 commit.
–author=pattern — 选中所有作者名字和 pattern 相匹配的 commit. 作者和提交者是有区别的, 作者是指实际上对目录中的内容做出更改的那个人, 而提交者是将这个更改加入到 repository 中的人. 对于本地仓库来说, 作者和提交者总是一样的, 但是比如说某些更改是通过邮件发送的, 那么作者和提交者往往是不同的.
–no-merges — 顾名思义, 是指选中所有只有一个父 commit 的 commit, 即将所有 merge commit 排除在外.

Most of these options can be mixed-and-matched. Here is an example which shows the following log entries: changes made to the current branch (branched from master), by myself, within the last month, which contain the text “foo”:

这些选项通常都可以混合使用. 下面这个例子是我选中在当前分支 (这是一个比 master 更快的分支, 比如 dev 分支) 中由我在过去一个月内写的, 并且还在 commit message 中含有 “foo” 的所有 commit:

$ git log --grep='foo' --author='johnw' --since="1 month ago" master..

1.7 Branching and the power of rebase | 分支, 以及 rebase 的力量

One of Git’s most capable commands for manipulating commits is the innocently-named rebase command. Basically, every branch you work from has one or more “base commits”: the commits that branch was born from. Take the following typical scenario, for example. Note that the arrows point back in time because each commit references its parent(s), but not its children. Therefore, the D and Z commits represent the heads of their respective branches:

Git 最好用的命令之一就是操作 commit 的 rebase 命令, 顾名思义, rebase 是用来更改 commit 的 base 的. 通常来说, 你的每个分支都会有一个或者是更多个的 “base commits”: 指你的分支是从哪个 commit 开始创建的. 以下面这张图描述的这种典型情况为例, 我们可以注意到箭头是指向父 commit 的, 而不是指向子 commit, 因为实际上是子 commit 中含有对父 commit 的引用. 我们通常将 D 和 Z 视作它们所在分支的 HEAD:

In this case, running branch would show two “heads”: D and Z, with the common parent of both branches being A. The output of show-branch shows us just this information:

在如上图所示的这个情况中, 我们可以看到这些分支一共有两个 “HEAD": D 和 Z, 它们的公共祖先是 A. show-branch 指令的输出结果向我们展示了这一点:

$ git branch
Z
* D
$ git show-branch
! [Z] Z
* [D] D
--
* [D] D
* [D^] C
* [D~2] B
+ [Z]Z
+ [Z^]Y
+ [Z~2] X
+ [Z~3] W
+* [D~3] A

Reading this output takes a little getting used to, but essentially it’s no different from the diagram above. Here’s what it tells us:

阅读这个输出需要我们花一点时间来习惯它, 但是它实际上给出的信息和上面那张示意图没有什么区别. 以下是这个输出的阅读方法⁹:

The branch we’re on experienced its first divergence at commit A (also known as commit D~3, and even Z~4 if you feel so inclined). The syntax commit^ is used to refer to the parent of a commit, while commit~3 refers to its third parent, or great-grandparent.

Reading from bottom to top, the first column (the plus signs) shows a divergent branch named Z with four commits: W, X, Y and Z.

The second column (the asterisks) show the commits which happened on the current branch, namely three commits: B, C and D.

The top of the output, separated from the bottom by a dividing line, identifies the branches displayed, which column their commits are labelled by, and the character used for the labeling.

我们目前在 repository 中拥有的两个分支是从 A 开始分支的.
从下往上读,第一列字符 (一列 +) 告诉我们, 分支 Z 在分叉后拥有的 commit 依次是: W, X, Y 还有 Z.
同样, 第二列字符 (一列 *) 告诉我们, 分支 D 在分叉后拥有的 commit 依次是: B, C 还有 D.
在整个输出的最上面有一些被 -- 分开的部分, 这里是在告诉我们分支的 HEAD 是谁, 以及下面的一系列输出中, 开头的第几列是和这个分支对应的, 使用 * 标注的分支是当前 checkout 的, 其他的分支 HEAD 使用 !, 而在接下来的部分中使用 +.

The action we’d like to perform is to bring the working branch Z back up to speed with the main branch, D. In other words, we want to incorporate the work from B, C, and D into Z.

我们接下来想做的事情是把分支 Z 并入主分支 D. 换句话说, 我们希望把B, C 以及 D 做出的更改也写进 Z.

In other version control systems this sort of thing can only be done using a “branch merge”. In fact, a branch merge can still be done in Git, using merge, and remains needful in the case where Z is a published branch and we don’t want to alter its commit history. Here are the commands to run:

在其他的版本控制系统中, 这是一件只能通过 “分支合并” 操作完成的事情. 而实际上所谓的分支合并在 Git 中也是可以被完成的, 只要使用 merge 命令就可以了, 如果我们不想更改 Z 的 commit 历史, 那么我们可以运行这些命令:

$ git checkout Z # switch to the Z branch
$ git merge D # merge commits B, C and D into Z

This is what the repository looks like afterward:

运行完了以后你的 repository 看起来会像是下面图中的这样:

If we checked out the Z branch now, it would contain the contents of the previous Z (now referenceable as Z^), merged with the contents of D. (Though note: a real merge operation would have required resolving any conflicts between the states of D and Z).

如果我现在检出分支 Z, 注意 “分支 Z” 只是一个 commit 的别名, 它曾经指 commit Z, 而现在它是图中的 Z', 分支 Z (现在指代 commit Z) 现在会包含 commit Z 和 commit D 合并过后的内容. 当然, 要进行一个 merge 操作需要先处理所有 D 和 Z 之间的冲突.

Although the new Z now contains the changes from D, it also includes a new commit to represent the merging of Z with D: the commit now shown as Z ’. This commit doesn’t add anything new, but represents the work done to bring D and Z together. In a sense it’s a “meta-commit”, because its contents are related to work done solely in the repository, and not to new work done in the working tree.

在新的 Z 现在包含了 D 中做出的更改的同时, 在新 Z 中同样存在着一个新的 commit, 这个 commit 是用来合并 Z 和 D 的: 就是上图中的 Z'. 这个 commit 很可能没有添加任何新的更改, 只是意味着做了一些工作将 D 和 Z 合并到了一起. 某种意义上来说, 这算是一种 “meta-commit”, 因为它的内容只是对 repository 的更改, 而不是对 working tree 的更改.

There is a way, however, to transplant the Z branch straight onto D, effectively moving it forward in time: by using the powerful rebase command. Here’s the graph we’re aiming for:

实际上还有一种办法能直接将分支 Z 移植到 D 上, 通过 rebase 命令, 可以直接把 D 快进. 如下图所示:

This state of affairs most directly represents what we’d like done: for our local, development branch Z to be based on the latest work in the main branch D. That’s why the command is called “rebase”, because it changes the base commit of the branch it’s run from. If you run it repeatedly, you can carry forward a set of patches indefinitely, always staying up-to-date with the main branch, but without adding unnecessary merge commits to your development branch. Here are the commands to run, compared to the merge operation performed above:

我们可以这样来描述我们实际上想干啥: 我们直接把我们在本地进行开发的分支 Z 的 “base commit” 改成了 D. 这正是上问提到的 rebase 命令为什么会被称作 “rebase”. 如果你不停地运行这个命令, 就可以在没有额外的 merge commit 的情况下更新主分支的数据. 以下是运行 rebase 需要的指令:

$ git checkout Z # switch to the Z branch
$ git rebase D # change Z’s base commit to point to D

Why is this only for local branches? Because every time you rebase, you’re potentially changing every commit in the branch. Earlier, when W was based on A, it contained only the changes needed to transform A into W. After running rebase, however, W will be rewritten to contain the changes necessary to transform D into W’. Even the transformation from W to X is changed, because A+W+X is now D+W’+X’ — and so on. If this were a branch whose changes are seen by other people, and any of your downstream consumers had created their own local branches off of Z, their branches would now point to the old Z, not the new Z’.

为什么我们说这种操作只能对本地分支进行呢? 这是因为每当运行 rebase 命令的时候, 我们实际上将分支中的每一个 commit 都进行了更改. 之前的 W 是基于 A 做出的修改, 如果我们认为一个 commit 中只包含更改的信息的话¹⁰, 那么 W 实际上只含有 “从 A 变成 W” 做出的变化. 但是运行完 rebase 之后, W 实际上就包含了从 D 变成 W' 产生的变化. 以及 W 和 X 之间的更改都产生了改变, 因为原来的 A+W+X 现在是 D+W'+X' — 其他的 commit 也有类似的变化. 如果这样的一个分支中的更改对于其他人来说是可见的, 以及从你的 repository 中获得源代码的下游人员中有人用原来的 Z 创建了新的分支, 那么他们的 Z 并不会指向 rebase 后的那个新 Z.

Generally, the following rule of thumb can be used: Use rebase if you have a local branch with no other branches that have branched off from it, and use merge for all other cases. merge is also useful when you’re ready to pull your local branch’s changes back into the main branch.

通常来说, 以下的经验法则是很有用的: 只要一个本地分支上没有再分出其他的分支, 那么我们就使用 rebase 命令来合并分支, 其他的情况一律使用 merge. merge 这个命令在你想把你的本地分支合并进主分支的时候很有用.

1.8 Interactive rebasing | 交互式的 rebase 命令

When rebase was run above, it automatically rewrote all the commits from W to Z in order to rebase the Z branch onto the D commit (i.e., the head commit of the D branch). You can, however, take complete control over how this rewriting is done. If you supply the -i option to rebase, it will pop you into an editing buffer where you can choose what should be done for every commit in the local Z branch:

就像上面说的那样, 当你运行一个 rebase 命令的时候, 它将为了将 Z 分支的 base 更改到分支 D 的 HEAD 上, 而自动的重写从 W 到 Z 的所有 commit. 其实你是完全可以控制这个重写的过程的. 给 rebase 传递一个 -i 参数, 那么你将进入一个可编辑的缓冲区, 在这个界面里, 你可以选择到底应该对 Z 分支上的每个 commit 做些什么:

pick — This is the default behavior chosen for every commit in the branch if you don’t use interactive mode. It means that the commit in question should be applied to its (now rewritten) parent commit. For every commit that involves conflicts, the rebase command gives you an opportunity to resolve them.

pick — 这是如果你不使用交互模式的时候会执行的默认操作, 它意味着你选中了这个分支中的每一个 commit, 也就是说: 每一个分支上的 commit 都将更改自己的父 commit 到它被重写过的父 commit 上. 对于每个可能产生冲突的 commit, 你会有机会解决它们.

squash — A squashed commit will have its contents “folded” into the contents of the commit preceding it. This can be done any number of times. If you took the example branch above and squashed all of its commits (except the first, which must be a pick in order to squash), you would end up with a new Z branch containing only one commit on top of D. Useful if you have changes spread over multiple commits, but you’d like the history rewritten to show them all as a single commit.

squash — 一个被 “压扁” 的 commit 将会将它之中的更改 “折叠” 进它的新父 commit 里. 这个操作可以不限次数地进行. 如果你对上面说的那个例子, 将除了第一个 commit 以外 (为了进行 squash 需要先进行一个 pick) 的所有 commit “压扁”, 那么你将会将分支 D 中的所有更改折叠成一个 commit, 然后将这个 commit 应用在分支 Z 上. 如果你不想保留更改历史, 只想留下一个 commit 的话, 这个模式还挺好用的.

edit — If you mark a commit as edit, the rebasing process will stop at that commit and leave you at the shell with the current working tree set to reflect that commit. The index will have all the commit’s changes registered for inclusion when you run commit. You can thus make whatever changes you like: amend a change, undo a change, etc.; and after committing, and running rebase --continue, the commit will be rewritten as if those changes had been made originally.

edit — 如果你将一个 commit 标记为了 edit 模式, 那么这个 rebase 命令将在这个 commit 这里停下来, 然后让你在你的 working tree 中编辑文件, 你可以重做一次这个 commit 做过的修改. 随后你运行 commit 命令的时候, the index 中将会含有所有已经提交的更改. 你可能会在类似以下的情况下使用这个模式: 添加一个更改到这个 commit 中, 或者说撤销一个更改. 在你提交 commit 之后, 运行 rebase --continue, 那个被标记为 edit 的 commit 将会被你新编辑的这个 commit 代替.

(drop) — If you remove a commit from the interactive rebase file, or if you comment it out, the commit will simply disappear as if it had never been checked in. Note that this can cause merge conflicts if any of the later commits in the branch depended on those changes.

(drop) — 如果你打算删除一个 commit. 这个 commit 将会像是从来没有被记录过一样不复存在. 注意:如果后续的其他 commit 是基于这个 commit 的更改的, 那么这个操作很可能引起合并冲突.

The power of this command is hard to appreciate at first, but it grants you virtually unlimited control over the shape of any branch. You can use it to:

交互式的 rebase 命令的用处很难一下子说清, 但是这个命令让你有了几乎不受限制的能力, 来对任何分支做出任何形式的调整. 你实际上可以用这个命令来:

Collapse multiple commits into single ones.

Re-order commits.

Remove incorrect changes you now regret.

Move the base of your branch onto any other commit in the repository.

Modify a single commit, to amend a change long after the fact.

将多个 commit 折叠成一个.
重新调整 commit 的顺序.
将不正确的更改删除.
将你的分支的 base 移动到你的 repository 中的任何一个 commit 上.
更改一个单独的 commit, 比如说在实际上这个 commit 已经被提交很久之后, 往里面添加更改.

I recommend reading the man page for rebase at this point, as it contains several good examples how the true power of this beast may be unleashed. To give you one last taste of how potent a tool this is, consider the following scenario and what you’d do if one day you wanted to migrate the secondary branch L to become the new head of Z:

我在这里十分建议读者阅读一下 rebase 的帮助页面. 其中有几个可以帮助你理解这个强大命令的能力到底应该被如果使用的优秀例子. 为了让读者至少对这个工具到底有多屌有一点点的认识, 我们来看一下下面这个例子:

如果你打算将分支 L 迁移到分支 Z 上, 并且使得 commit L 是分支 Z 的新 HEAD, 你会怎么做呢?

The picture reads: we have our main-line of development, D, which three commits ago was branched to begin speculative development on Z. At some point in the middle of all this, back when C and X were the heads of their respective branches, we decided to begin another speculation which finally produced L. Now we’ve found that L’s code is good, but not quite good enough to merge back over to the main-line, so we decide to move those changes over to the development branch Z, making it look as though we’d done them all on one branch after all. Oh, and while we’re at it, we want to edit J real quick to change the copyright date, since we forgot it was 2008 when we made the change! Here are the commands needed to untangle this knot:

这个图实际上在说: 我们主要的开发发生在分支 D 上, 而这个分支 D 在三个 commit 之前, 分支出了一个 Z 来进行试探性质的开发. 在 C 和 X 还是分支的 HEAD 的时候, 有人尝试合并了两个分支, 进行了新一轮的试探性开发, 最终产出了分支 L. 那么现在我们知道了 commit L 的代码是很优秀的, 但是还没有优秀到足以合并回主分支的程度, 我们为了进一步改进这个代码, 希望把 L 上的更改移动到分支 Z 上, 然后调整得足够好了以后, 再合并回主分支. 顺便, 我们在做这一切的同时, 还希望编辑一下 commit J 来简单的变更一下版权信息的日期, 因为当初提交 commit J 的时候忘了改它. 那么以下是解决以上这些麻烦的问题所需要的命令:

$ git checkout L
$ git rebase -i Z

After resolving whatever conflicts emerge, I now have this repository:

处理完冲突以后, 我的 repository 看起来像下图这样:

As you can see, when it comes to local development, rebasing gives you unlimited control over how your commits appear in the repository.

就像你看到的那样, 如果只是本地开发, rebase 让你几乎有了对 commit 完全的控制能力, 你想让他们是什么样子就可以是什么样子.

2 The Index

2.1 The Index: Meet the middle man | The Index : 中间人

Between your data files, which are stored on the filesystem, and your Git blobs, which are stored in the repository, there stands a somewhat strange entity: the Git index. Part of what makes this beast hard to understand is that it’s got a rather unfortunate name. It’s an index in the sense that it refers to the set of newly created trees and blobs which you created by running add. These new objects will soon get bound into a new tree for the purpose of committing to your repository — but until then, they are only referenced by the index. That means that if you unregister a change from the index with reset, you’ll end up with an orphaned blob that will get deleted at some point at the future.

在你存储在文件系统中的数据文件, 与 Git 中存储的 blob 之间还存在着一个奇怪的媒介, 我们称之为 the Git index. 这个令人困惑的名字使得它很难被人理解. 从某种意义上来讲, 它确实是一种索引: 它引用一个由新添加的 tree¹¹ 和 blob 组成的集合, 这个集合是用户通过运行 add 命令创建的. 在这些对象真正被添加到一个 tree, 并且最终成为一个 commit 加入到你的 repository 中之前, 这些新的对象, 它们仅仅只被 the index 引用而已. 这意味着如果你通过 reset 命令将一个被记录到 the index 中的更改撤销掉的话, 那么你原本新创建的 blob 会成为没有人引用的孤儿, 这种 blob 在未来的某个时间点会被删除.

The index is really just a staging area for your next commit, and there’s a good reason why it exists: it supports a model of development that may be foreign to users of CVS or Subversion, but which is all too familiar to Darcs users: the ability to build up your next commit in stages.

The index 实际上起到的作用只是一个为你的下一个 commit 而设立的暂存区罢了. 它使得你有了在一个暂存区里搭建你的下一个 commit 的能力, 这种开发方式对于 Darcs 的用户来说相对熟悉, 而对于 CVS 或者是 Subversion 的用户来说这可能会很陌生.

First, let me say that there is a way to ignore the index almost entirely: by passing the -a flag to commit. Look at the way Subversion works, for example. When you type svn status, what you’ll see is a list of actions to be applied to your repository on the next call to svn commit. In a way, this “list of next actions” is a kind of informal index, determined by comparing the state of your working tree with the state of HEAD. If the file foo.c has been changed, on your next commit those changes will be saved. If an unknown file has a question mark next to it, it will be ignored; but a new file which has been added with svn add will get added to the repository.

首先, 实际上是有一种办法能几乎忽略掉 the index 的方法的: 只要在使用 commit 命令的时候传递 -a 这个参数, 就可以了. 我们以 Subversion 的工作方式为例. 我们输入 svn status, 这个命令的输出是一个关于你的下一个 svn commit 命令将对于你的 repository 做出怎样的更改的列表. 在这个例子中, 那个列表可以看作是 Git 中的 the index, 毕竟这个通过比较你当前 working tree 和 HEAD 之间的状态差异而得到的列表, 从某种程度上来说是一种信息的索引. 比方说如果文件 foo.c 被更改了, 那么就会出现在这个列表中, 这意味着你的下一个 commit 会将这个更改写入你的 repository 中. 如果一个文件的后面有一个 ?, 那么意味着这个文件将被版本管理系统忽略; 但是如果通过 snv add 将文件添加进管理, 那么这个文件将被加入到 repository 中.

This is no different from what happens if you use commit -a: new, unknown files are ignored, but new files which have been added with add are added to the repository, as are any changes to existing files. This interaction is nearly identical with the Subversion way of doing things.

实际上当你在 Git 中使用 commit -a 命令的时候, 发生的事情几乎和上面描述的一致: 新建的文件需要使用 add 手动添加, 否则就像被忽略的文件一样, 并不会被添加进 repository. 而以前添加过的文件中的更改则会被加入 repository. 这个交互方式几乎和 Subversion 没有什么区别.

The real difference is that in the Subversion case, your “list of next actions” is always determined by looking at the current working tree. In Git, the “list of next actions” is the contents of the index, which represents what will become the next state of HEAD, and that you can manipulate directly before executing commit. This gives you an extra layer of control over what ’s going to happen, by allowing you to stage those changes in advance.

这两者之间的区别实际上在于, 在 Subversion 中, 那个列表总是通过检查你的当前工作区来列出的. 而在 Git 中, 这个列表的功能, 由 the index 中记录的内容来承担. 这个 the index 中指示着 HEAD 这个 commit 接下来会是什么样的状态, 而你可以在 commit 之前直接对 the index 做出调整. 这实际上让你对更改的控制能力变得更强了.

If this isn’t clear yet, consider the following example: you have a trusty source file, foo.c, and you’ve made two sets of unrelated changes to it. What you’d like to do is to tease apart these changes into two different commits, each with its own description. Here’s how you’d do this in Subversion:

如果上面这种说法还不够明确. 那么我们可以考虑一下下面这个例子: 你有一个可以信任的源文件, 它是 foo.c, 你还有对他做出了两组没什么关联的更改. 你现在想做的事情是将这两个更改分成两个不同的 commit 进行提交, 每个 commit 都有它自己的说明. 那么你在 Subversion 中应该这么做:

$ svn diff foo.c > foo.patch
$ vi foo.patch
<edit foo.patch, keeping the changes I want to commit later>
$ patch -p1 -R < foo.patch # remove the second set of changes
$ svn commit -m "First commit message"
$ patch -p1 < foo.patch # re-apply the remaining changes
$ svn commit -m "Second commit message"

Sounds like fun? Now repeat that many times over for a complex, dynamic set of changes. Here’s the Git version, making use of the index:

听起来不错? 但是如果你如果用对付的是更复杂的情况呢? 下面是 Git 中的做法, 让我们利用 the index:

$ git add --patch foo.c
<select the hunks I want to commit first>
$ git commit -m "First commit message"
$ git add foo.c # add the remaining changes
$ git commit -m "Second commit message"

What’s more, it gets even easier! If you like Emacs, the superlative tool gitsum.el, by Christian Neukirchan, puts a beautiful face on this potentially tedious process. I recently used it to tease apart 11 separate commits from a set of conflated changes. Thank

这是不是简单多了? 如果你喜欢 Emacs, 那么还有个工具叫 gitsum.el, 这个工具是由 Christian Neukirchan 开发的, 给这个可能看起来单调乏味的过程添加了一个漂亮的界面. 我最近实际上用它将一个更改拆分成 11 个独立的 commit 过. 真是谢谢 TA 了.

2.2 Taking the index further | 进一步了解 the index

Let’s see, the index… With it you can pre-stage a set of changes, thus iteratively building up a patch before committing it to the repository. Now, where have I heard that concept before…

根据上面所说的,我们可以如此来描述 the index 的功能: 通过它, 我们可以将一系列更改暂存下来, 还可以在更改提交到 repository 之前, 将一次对分拣的更改分成若干的 patch. 我好像曾经在什么地方听到过这个…

If you’re thinking “Quilt!”, you’re exactly right. In fact, the index is little different from Quilt, it just adds the restriction of allowing only one patch to be constructed at a time.

你很可能会想到一个叫 “Quilt” 的软件. 事实上, the index 和 Quilt 有一点点不同, Quilt 实际上只是添加了一个 “一次只允许对代码做出一个 patch 的更改” 的限定而已¹².

But what if, instead of two sets of changes within foo.c, I had four? With plain Git, I’d have to tease each one out, commit it, and then tease out the next. This is made much easier using the index, but what if I wanted to test those changes in various combinations with each other before checking them in? That is, if I labelled the patches A, B, C and D, what if I wanted to test A + B, then A + C, then A + D, etc., before deciding if any of the changes were truly complete?

但是如果我在文件 foo.c 中实际上一共有四组的更改呢? 在原生的 Git 中, 我实际上需要一个一个的将属于其中一个 patch 的更改挑选出来, commit, 然后再回去选下一组的. The index 实际上已经大大简化了这个过程, 但是如果我想在提交这些更改前, 对这些更改的多种组合分别做测试呢? 比方说我有四个 patch, 它们分别是 A, B, C, D. 如果我想以这种顺序进行测试: A + B, 然后 A + C, 随后 A + D, 以此类推. 那么我应该怎么做呢?

There is no mechanism in Git itself that allows you to mix and match parallel sets of changes on the fly. Sure, multiple branches can let you do parallel development, and the index lets you stage multiple changes into a series of commits, but you can’t do both at once: staging a series of patches while at the same time selectively enabling and disabling some of them, to verify the integrity of the patches in concert before finally committing them. What you ’d need in order to do something like this would be an index which allows for greater depth than one commit at a time. This is exactly what Stacked Git provides.

Here’s how I’d commit two different patches into my working tree using plain Git:

在 Git 中并没有这样的功能. 多分支确实可以让你完成平行开发, the index 也确实可以让你将更改拆成若干个 commit, 但是实际上你并不能同时做这两个事情: 你不能暂存下一系列 commit 中的更改, 然后去选择其中一些出于启用/关闭的状态, 以此来在提交前验证更改的正确性.

你实际上想做的事情是希望你的 the index 中, 可以存下多个 commit¹³, 这个功能实际上可以由 Stacked Git 来提供的.

以下是我 commit 两个不同的更改组到我的 working tree 的过程:

$ git add -i # select first set of changes
$ git commit -m "First commit message"
$ git add -i # select second set of changes
$ git commit -m "Second commit message"

This works great, but I can’t selectively disable the first commit in order to test the second one alone. To do that, I’d have to do the following:

这样实际上还不错, 但是我无法在做完这一切之后, 再将第一个 commit 暂时禁用, 来单独测试第二个 commit. 如果我想做这个事情, 那么我接下来还得做这么一个事情:

$ git log # find the hash id of the first commit
$ git checkout -b work <first commit’s hash id>
$ git cherry-pick <second commit’s hash id>
<... run tests ...>
$ git checkout master # go back to the master "branch"
$ git branch -D work # remove my temporary branch

Surely there has to be a better way! With stg I can queue up both patches and then re-apply them in whatever order I like, for independent or combined testing, etc. Here’s how I’d queue the same two patches from the previous example, using stg:

但是应该会有更好的方法. 使用 stg 命令, 我可以对两个 patch 进行任意顺序的排序, 然后按这个顺序来应用它. 这样就可以进行独立测试/组合测试了. 以下是一个例子:

$ stg new patch1
$ git add -i # select first set of changes
$ stg refresh --index
$ stg new patch2
$ git add -i # select second set of changes
$ stg refresh --index

Now if I want to selectively disable the first patch to test only the second, it’s very straightforward:

那么完成上面说的事情就非常简单了:

$ stg applied
patch1
patch2
<... do tests using both patches ...>
$ stg pop patch1
<... do tests using only patch2 ...>
$ stg pop patch2
$ stg push patch1
<... do tests using only patch1 ...>
$ stg push -a
$ stg commit -a # commit all the patches

This is definitely easier than creating temporary branches and using cherry-pick to apply specific commit ids, followed by deleting the temporary branch.

这比上面提到的建立临时分支并使用 cherry-pick 来应用特别的 commit 哈希值, 后面再把他删掉的方式舒服多了.

3 Reset

3.1 To reset, or not to reset | 要不要 reset, 这是一个问题

One of the more difficult commands to master in Git is reset, which seems to bite people more often than other commands. Which is understandable, giving that it has the potential to change both your working tree and your current HEAD reference. So I thought a quick review of this command would be useful.

在 Git 中比较麻烦的命令之一就是 reset, 大家似乎都更容易在这个命令上遇到问题. 看起来这个命令由于同时更改了你的 working tree 和你当前的 HEAD 指针, 所以会显得难以理解. 所以我这里需要快速提一下这个命令的作用.

Basically, reset is a reference editor, an index editor, and a working tree editor. This is partly what makes it so confusing, because it’s capable of doing so many jobs. Let’s examine the difference between these three modes, and how they fit into the Git commit model.

简单来说, reset 是一个能编辑 HEAD / index / working tree 的工具. 这可以部分解释它为什么看起来这么难懂, 因为它实际上确实一下子完成了很多很多工作. 我们会在下面慢慢解释上面提到的三种模式之间的区别, 以及它们在我们前文建立的, 从 commit 的角度理解 Git 的模型中, 到底是如何工作的.

3.2 Doing a mixed reset | 应用一个 mixed reset

If you use the --mixed option (or no option at all, as this is the default), reset will revert parts of your index along with your HEAD reference to match the given commit. The main difference from --soft is that --soft only changes the meaning of HEAD and doesn’t touch the index.

如果你使用了 --mixed 这个选项 (如果你不带参数调用, 那么默认就是它), reset 命令会在将你的 HEAD 指针指向给定的那个 commit, 同时调整 index, 使其与 HEAD 匹配. --soft 和这个选项的区别在于, --soft 并没有更改 index.

$ git add foo.c # add changes to the index as a new blob
$ git reset HEAD # delete any changes staged in the index
$ git add foo.c # made a mistake, add it back

3.3 Doing a soft reset | 应用一个 soft reset

If you use the --soft option to reset, this is the same as simply changing your HEAD reference to a different commit. Your working tree changes are left untouched. This means the following two commands are equivalent:

如果你加上了 --soft 选项, 那么这个 reset 命令就非常的简单易懂了: 实际上和你直接把你的 HEAD 指针指向了另一个不同的 commit 没什么两样. 你的 working tree 中的所有更改都会在执行完 reset 之后原样保留. 这意味着下面写的两条命令是完全等价的:

$ git reset --soft HEAD^ # backup HEAD to its parent,
# effectively ignoring the last commit
$ git update-ref HEAD HEAD^ # does the same thing, albeit manually

In both cases, your working tree now sits on top of an older HEAD, so you should see more changes if you run status. It’s not that your files have been changed, simply that they are now being compared against an older version. It can give you a chance to create a new commit in place of the old one. In fact, if the commit you want to change is the most recent one checked in, you can use commit --amend to add your latest changes to the last commit as if you’d done them together.

在上述的两种情况里, 运行完 reset 之后, 你的 working tree 中的文件内容是领先于你的 HEAD 的, 所以如果你运行 status 命令来查看变更的情况, 你会看到的实际上是你的 working tree 和一个更老的 HEAD 的差别. 这使得你可以在老的 HEAD 上重新建立一个新的 commit, 事实上 commit --amend 这个命令做的事情就是类似于这样的.

But please note: if you have downstream consumers, and they’ve done work on top of your previous head — the one you threw away — changing HEAD like this will force a merge to happen automatically after their next pull. Below is what your tree would look like after a soft reset and a new commit:

但是请注意一下: 如果你有下游用户, 而他们使用了被你 reset + commit 之后丢弃掉的那个 commit 的话, 那么像这样去更改你的 HEAD, 将会在他们的下一个 pull 时导致一个自动出现的强制 merge. 下图是你的 repository 在执行完 soft reset 之后又提交了一个新的 commit 之后的样子:

And here’s what your consumer’s HEAD would look like after they pulled again, with colors to show how the various commits match up:

而下图是你的下游用户下一次 pull 之后的情况:

可以从其中给 commit 上的颜色看出来这些 commit 是如何对应的.

3.4 Doing a hard reset | 应用一个 hard reset

A hard reset (the --hard option) has the potential of being very dangerous, as it’s able to do two different things at once:

hard reset 操作起来有一定的风险, 它能同时完成两件不同的事情:

First, if you do a hard reset against your current HEAD, it will erase all changes in your working tree, so that your current files match the contents of HEAD. There is also another command, checkout, which operates just like reset --hard if the index is empty. Otherwise, it forces your working tree to match the index.

首先, 如果你对你当前的 HEAD 做 hard reset, 这将从你的 working tree 中抹去所有的更改, 这样一来你的 working tree 就和你的 HEAD 指向的那个 commit 完全一致了. 如果你的 index 是空的的话, 其实还有一个命令叫 checkout 同样能做到这个事情. 如果你的 index 不空, 那么对某个文件进行 checkout 命令只会使得 working tree 中的文件和 index 中一致.

Now, if you do a hard reset against an earlier commit, it’s the same as first doing a soft reset and then using reset --hard to reset your working tree. Thus, the following commands are equivalent:

如果你对一个之前的 commit 调用 reset 命令, 那么这个事情和先使用 soft reset 之后再使用 hard reset 来重置你的工作区是完全一致的. 所以说下面的两组命令是等价的:

$ git reset --hard HEAD~3 # Go back in time, throwing away changes
$ git reset --soft HEAD~3 # Set HEAD to point to an earlier commit
$ git reset --hard # Wipe out differences in the working tree

As you can see, doing a hard reset can be very destructive. Fortunately, there is a safer way to achieve the same effect, using the Git stash (see the next section):

读过以上的内容, 我们可以发现: 一个 hard reset 很可能是具有破环性的. 幸运的是, 我们实际上有一种更安全的方法来完成同样的事情, 只要使用下一节中提到的 Git stash 命令就可以了:

$ git stash
$ git checkout -b new-branch HEAD~3 # head back in time!

This approach has two distinct advantages if you’re not sure whether you really want to modify the current branch just now:

当你并不确定你是否要对当前的分支进行修改的时候, 这种方法有两个明显的优点:

It saves your work in the stash, which you can come back to at any time. Note that the stash is not branch specific, so you could potentially stash the state of your tree while on one branch, and later apply the differences to another.

It reverts your working tree back to a past state, but on a new branch, so if you decide to commit your changes against the past state, you won’t have altered your original branch.

这样可以将你的工作保存在 stash 中, 你随时可以再回到你原来的工作状态. 需要注意的是这个 stash 和分支无关, 你完全可以在某个分支上将你当前的 working tree 存入, 而随后在另一个分支上取出它.
这样操作的确将代码回退到了过去的状态, 但是是在一个新的分支上, 如果你决定在过去的状态上修改, 这并不会影响到你原先那个更快的分支.

If you do make changes to new-branch and then decide you want it to become your new master branch, run the following commands:

如果你对 new-branch 做出了更改, 然后想让它成为你新的主分支, 可以运行以下的命令来完成这件事情:

$ git branch -D master # goodbye old master (still in reflog)
$ git branch -m new-branch master # the new-branch is now my master

The moral of this story is: although you can do major surgery on your current branch using reset --soft and reset --hard (which changes the working tree too), why would you want to? Git makes working with branches so easy and cheap, it’s almost always worth it to do your destructive modifications on a branch, and then move that branch over to take the place of your old master. It has an almost Sith-like appeal to it…

以上的事情是在告诉你: 尽管你是可以用 reset –soft 和 reset –hard 命令来操作你当前的分支,但是你几乎没有理由必须在你当前的分支上这么做. Git 让分支相关的操作变得简洁而容易, 所以我们往往都将可能有破坏性的操作放在另一个分支上操作, 完成以后再移动回来, 这种操作方式几乎在任何情况下都比直接在原分支上修改更为优秀.¹⁴

And what if you do accidentally run reset --hard, losing not only your current changes but also removing commits from your master branch? Well, unless you’ve gotten into the habit of using stash to take snapshots (see next section), there’s nothing you can do to recover your lost working tree. But you can restore your branch to its previous state by again using reset --hard with the reflog (this will also be explained in the next section):

那么如果你不小心运行了 hard reset, 然后同时丢失了你当前的更改和之前的一部分 commit 有办法弥补么? 除非你已经养成了使用 stash 来建立快照, 否则几乎没有办法来挽回这种情况对于 working tree 带来的损失, 但是你可以将你的分支回溯到它之前的那个状态. 只要像下面这样使用 reset --hard 这个命令就可以了:

$ git reset --hard HEAD@{1} # restore from reflog before the change

下一节我们来解释上面这条命令的意思.

To be on the safe side, never use reset --hard without first running stash. It will save you many white hairs later on. If you did run stash, you can now use it to recover your working tree changes as well:

为了安全起见, 我们不应该在运行 stash 之前使用 reset --hard. 这个习惯将让你少掉几根头发. 如果你跑过 stash, 你实际上就可以使用它来还原你的 working tree:

$ git stash # because it's always a good thing to do
$ git reset --hard HEAD~3 # go back in time
$ git reset --hard HEAD@{1} # oops, that was a mistake, undo it!
$ git stash apply # and bring back my working tree changes

4 Stashing and the reflog | Stash 和 reflog

Until now we’ve described two ways in which blobs find their way into Git: first they’re created in your index, both without a parent tree and without an owning commit; and then they’re committed into the repository, where they live as leaves hanging off of the tree held by that commit. But there are two other ways a blob can dwell in your repository.

直到现在我们描述过两种在 Git 中找到某个 blob 的方法:

当 blob 在你的 index 中被创建时, 此时还没有一个 tree 在引用它们, 它们也没有被某个 commit 所拥有, 这时我们可以通过 index 来找到它;
随后它们被提交给你的 repository, 之后 blob 就成为了被某个 commit 管理的 tree 上的叶节点.

但是实际上在 Git 中还有两种 blob 存在的形式.

The first of these is the Git reflog, a kind of meta-repository that records — in the form of commits — every change you make to your repository. This means that when you create a tree from your index and store it under a commit (all of which is done by commit), you are also inadvertently adding that commit to the reflog, which can be viewed using the following command:

第一种就是 Git reflog, 这是一种以 commit 的方式记录了所有你对你的 repository 做出的更改的 meta-repository. 这意味着当你从一个 index 建立一个 tree, 并且将它存在一个 commit 中的时候, 你实际上无意之中也将这个 commit 添加到了 the reflog 中. 你可以通过以下的命令查看 the reflog:

$ git reflog
5f1bc85... HEAD@{0}: commit (initial): Initial commit

The beauty of the reflog is that it persists independently of other changes in your repository. This means I could unlink the above commit from my repository (using reset), yet it would still be referenced by the reflog for another 30 days, protecting it from garbage collection. This gives me a month’s chance to recover the commit should I discover I really need it.

the reflog 的妙处就在于它与其他你对你的 repository 做出的更改是独立的. 这意味着当我将上面的命令展示的那个 commit 从我的 repository 中解除链接的时候 (比方说我跑了一个 reset), 这个 commit 仍然被这个 meta-repository, 也就是 the reflog 所引用, 直到 30 天以后, 这个 commit 才会进入垃圾回收系统的考虑范围. 这使得你有一个月的时间来找回你需要的 commit.

The other place blobs can exist, albeit indirectly, is in your working tree itself. What I mean is, say you’ve changed a file foo.c but you haven’t added those changes to the index yet. Git may not have created a blob for you, but those changes do exist, meaning the content exists — it just lives in your filesystem instead of Git’s repository. The file even has its own SHA1 hash id, despite the fact no real blob exists. You can view it with this command:

尽管很显然, 但是实际上还有一个地方是 blob 可以呆的, 那就是你的 working tree. 我的意思是说, 如果你更改了一个文件, 比如说 foo.c 但是还没有将这个更改添加到 the index 中, 那么由于我们说 blob 的本质是数据本身, 所以即使 Git 并没有建立对应的 blob, 数据本身也仍然是存在的, 只不过是存在于你的文件系统中罢了. 这个文件本身实际上是有 SHA1 值的, 尽管其实并没有实际上的 blob 存在. 我们可以通过下面这条命令来查看它:

$ git hash-object foo.c
<some hash id>

What does this do for you? Well, if you find yourself hacking away on your working tree and you reach the end of a long day, a good habit to get into is to stash away your changes:

这意味着啥呢? 如果你在你的 working tree 中到处乱改, 然后经过了漫长的一整天工作, 将所有的更改都用 stash 存起来会是一个好习惯:

$ git stash

This takes all your directory’s contents — including both your working tree, and the state of the index — and creates blobs for them in the git repository, a tree to hold those blobs, and a pair of stash commits to hold the working tree and index and record the time when you did the stash.

这个命令将你的那个目录中的所有内容 — 包括你的 working tree, 甚至是 the index 的状态 — 都保存了下来, 并且为它们在 Git repository 中创建了 blob, 以及一个 tree 来管理这些 blob, 还有一对 stash commit 来管理你的 working tree 和 index 还得记录下你执行 stash 命令的时间.

This is a good practice because, although the next day you’ll just pull your changes back out of the stash with stash apply, you’ll have a reflog of all your stashed changes at the end of every day. Here’s what you’d do after coming back to work the next morning (WIP here stands for “Work in progress ”):

尽管你第二天会把所有的更改都用 stash apply 命令从 stash 中重新拉出来, 但是做完这件事情之后你相当于在 reflog 中存了一个你每天工作的结果的快照. 第二天你回来工作的时候需要做的事情如下:

$ git stash list
stash@{0}: WIP on master: 5f1bc85... Initial commit
$ git reflog show stash # same output, plus the stash commit's hash id 2add13e... stash@{0}: WIP on master: 5f1bc85... Initial commit
$ git stash apply

其中WIP意味着 “Work in progress”

Because your stashed working tree is stored under a commit, you can work with it like any other branch — at any time! This means you can view the log, see when you stashed it, and checkout any of your past working trees from the moment when you stashed them:

因为你已经把 working tree 存在了一个 commit 里面, 所以你任何时候都实际上可以把他当作一个分支一样来看待. 这意味着你甚至可以查看日志, 可以看你 stash 的时间, 以及将你过去存进 stash 的 working tree 重新取出:

$ git stash list
stash@{0}: WIP on master: 73ab4c1... Initial commit
...
stash@{32}: WIP on master: 5f1bc85... Initial commit
$ git log stash@{32} # when did I do it?
$ git show stash@{32} # show me what I was working on
$ git checkout -b temp stash@{32} # let’s see that old working tree!

This last command is particularly powerful: behold, I’m now playing around in an uncommitted working tree from over a month ago. I never even added those files to the index; I just used the simple expedient of calling stash before logging out each day (provided you actually had changes in your working tree to stash), and used stash apply when I logged back in.

最后那个命令其实非常的有用: 你看, 我可以把一个月前没有 commit 的 working tree 重新拿出来玩. 我甚至从来没有把这些文件添加到 the index 中; 只不过是在我每天下班关机之前运行了一次 stash 命令而已. 然后第二天上班的时候, 只要 stash apply 就行了.

If you ever want to clean up your stash list — say to keep only the last 30 days of activity — don’t use stash clear; use the reflog expire command instead:

但是如果你什么时候想清理你的 stash 列表了, 比方说想把 30 天之前的 stash 的历史删掉¹⁵, 那么麻烦不要使用 stash clear — 那样你将会丢失所有 stash 中的历史; 而应该使用 reflog expire 命令:

$ git stash clear # DON'T! You'll lose all that history
$ git reflog expire --expire=30.days refs/stash
<outputs the stash bundles that've been kept>

The beauty of stash is that it lets you apply unobtrusive version control to your working process itself: namely, the various stages of your working tree from day to day. You can even use stash on a regular basis if you like, with something like the following snapshot script:

stash 的妙处就在于让你可以做一些不那么刻意的版本控制, 比如说像上面那样每天保存一下工作进度. 你愿意的话甚至可以定期的运行 stash, 比如通过下面这样的脚本:

$ cat <<EOF > /usr/local/bin/git-snapshot
#!/bin/sh
git stash && git stash apply
EOF
$ chmod +x $_
$ git-snapshot

There’s no reason you couldn’t run this from a cron job every hour, along with running the reflog expire command every week or month.

没有什么理由能阻止你使用 cron 来每个小时跑一次这个命令, 如果担心仓库太大, 完全可以同时每个月或者每周跑 reflog expire.

5 Conclusion | 结论

Over the years I’ve used many version control systems, and many backup schemes. They all have facilities for retrieving the past contents of a file. Most of them have ways to show how a file has differed over time. Many permit you to go back in time, begin a divergent line of reasoning, and then later bring these new thoughts back to the present. Still fewer offer fine-grained control over that process, allowing you to collect your thoughts however you feel best to present your ideas to the public. Git lets you do all these things, and with relative ease — once you understand its fundamentals.

在过去的几年中我使用过非常多的版本控制系统, 以及很多种的备份模式. 它们都有一系列工具来追回过去文件的内容. 大部分工具都有展示一个文件随着时间发展如何一步步被更改的的方式. 很多工具都可以让你穿越时间回到过去, 让你在过去做一些尝试, 然后把产生的想法重新带回现在. 还是有很小一部分提供了对这个过程的良好的控制机制, 让你可以良好的操作过去的历史, 可以以任意你喜欢的方式整理好你的想法, 然后将它展示给公众. Git 可以让你做到上述的一切. 甚至相对来说还是比较容易地做到这一切 — 只要你真的搞懂了 Git 的原理.

It’s not the only system with this kind of power, nor does it always employ the best interface to its concepts. What it does have, however, is a solid base to work from. In the future, I imagine many new methods will be devised to take advantage of the flexibilities Git allows. Most other systems have led me to believe they’ve reached their conceptual plateau — that all else from now will be only a slow refinement of what I’ve seen before. Git gives me the opposite impression, however. I feel we’ve only begun to see the potential its deceptively simple design promises.

这不是唯一一个有这些能力的系统, 它也没有对于它的理念提供最好的交互. 但是 Git 拥有的这些东西, 却的的确确是一个进一步开发的好基础. 在未来, 我可以预想存在着很多更好的工具被发明出来, 它们能更好地利用 Git 类似的构造提供的这种种便利. 其他的大部分系统都让我相信它们到达了他们的瓶颈期 — 它们要不然就像我之前见到的那样在慢慢慢慢地进行改进, 要不然将来也会进入这样的状态. Git 却给了我一个更为乐观的印象. 我感觉我们即将见识到它出乎人意料的简单的涉及理念中爆发出来的潜力.

6 Further reading | 阅读更多

If your interest to learn Git more has been piqued, please check out the following articles:

如果你还想学一些 Git 可以看看下面这些文章:

A tour of Git: the basics - http://cworth.org/hgbook-git/tour/

Manage source code using Git - http://www.ibm.com/developerworks/linux/library/l-git/

A tutorial introduction to git - http://git-scm.com/docs/gittutorial

GitFaq — GitWiki - https://git.wiki.kernel.org/index.php/GitFaq

A git core tutorial for developers - http://www.kernel.org/pub/software/scm/git/docs/gitcore-tutorial.html

git for the confused - http://www.gelato.unsw.edu.au/archives/git/0512/13748.html

The thing About Git - http://tomayko.com/writings/the-thing-about-git

译者注: 这个描述貌似和上面对 working tree 的描述有冲突, 上面对 working tree 的说法是 working tree 包含了 .git 子目录,但是出于译者对 commit 的认识而言, commit 中应该没有 .git 中的相关信息. 这里可以尝试理解为文中说的 working tree 是类似工作区的概念, 并不包括 .git 子目录. ↩︎
译者注: 这个地方括号中的内容不知道怎么翻译, 可以理解为, “我们还有很多关于 commit 的东西马上就要谈到”, 但是感觉和上下文不搭. ↩︎
译者注: 有理由相信 github 可以用这个方式来省钱, 这样 fork 出来的 repository 就不会那么占空间了. ↩︎
译者注: 这个地方我皮了一下, 但是实际上我并不确定原文是不是这个意思. ↩︎
译者注: 最后这句话的翻译不确定是否正确. ↩︎
译者注: 这个时候真的还没有 “master” 这个分支么? 为什么可以说是 create 呢? ↩︎
译者注: 这里的 “first” 是按提交 commit 的时间排序的么? ↩︎
译者注: 毕竟你可以将 “name^” 看作是一个 “name” 嘛. ↩︎
译者注: 实际上这些内容可以在命令 git help show-branch 中看到. ↩︎
译者注: 虽然实际上并不是这样, 因为每个 commit 中的 tree 都只是一个快照而已.

另外上面这段话我个人觉得可以这样理解:

commit 是一个 object, 在 Git 中一个 object 的名字是由它的 SHA1 值来决定的, 而 SHA1 值是由内容决定的. 那么当我们说, 一个 commit 被改变的时候, 我们实际上想表达的意思是, 这个 commit 的 SHA1 值发生了变化, 也就是 commit 的内容发生了变化.

根据前文的说法我们知道, 一个 commit 中, 是包含有它的父 commit 的引用的, 如果一个 commit 的父 commit 被用 rebase 指令改掉了, 那么它本身的 SHA1 值是会发生变化的, 而它本身发生了变化之后, 所有直接或者间接引用了它的其他 commit 的值也都会因为这样的理由而发生变化. ↩︎
译者注: 这里的 tree 指的是被新 commit 直接管理的那个 tree 的 sub-tree. ↩︎
译者注: 这里我并不确定是不是这个意思, 因为译者并没有使用过 Quilt, 这句是根据维基猜的, 主要是前面那个 it 不知道指的是谁. ↩︎
译者注: 这里的意思应该是, 如果你的暂存区里有多个 commit, 那么你就可以把他们以任意的组合加到 repository 中, 然后就可以实现上面说的那个事情了. ↩︎
译者注: 最后一句貌似是个星战梗, 不知道啥意思. Sith 是西斯, 星战的反派. ↩︎
译者注: 这里按前文的说法, stash 的历史也一样是由 reflog 保存的, 那么 reflog 本身只会保存 30 天历史, 所以这里手动清理应该没什么意义吧, 除非只是希望手动完成一下垃圾回收器完成的事情? ↩︎

Starting sessions with systemd part 2

deepin 社区官方博客 — Wed, 29 Dec 2021 21:09:07 +0000

接着上一篇文章，这篇文章主要讲解一下具体的实现。

https://github.com/linuxdeepin/dde-session 已经包含了所有的文件和提交。

上面文章说过，为了让 dde 使用 systemd –user 来关系服务，我提供了一组服务：

dde-session-initialized.target
dde-session-manager.service
dde-session-manager.target
dde-session-pre.target
dde-session-restart-dbus.service
dde-session-shutdown.service
dde-session-shutdown.target
dde-session.target
dde-session-x11-services-ready.target
dde-session-x11-services.target
dde-session-x11.target
org.deepin.Session.service

lightdm 在认证通过以后，会启动 dde-session 进程，dde-session 会通过 systemd 的 dbus 启动 org.deepin.Session.service。

在 org.deepin.Session.service 中会执行 dde-session-ctl --systemd-service，启动 dde-session-x11.target.

dde-session-x11.target 关联了所有初始化的服务，systemd 会帮助自动运行这些服务，并且最终会运行到 dde-session-manager.service 上。

dde-session-manager.service

[Service]
Type=simple
ExecStart=/usr/bin/startdde
ExecStopPost=/usr/lib/libexec/dde-session-ctl --logout

在 org.deepin.Session.service 中会启动一个特殊的服务，这个服务会监听 dde-session 的退出，因为总要有一个服务去监听 session 的状态，要确保 session 在服务在，session 退服务退，服务退 session 退，共存亡，这也是所有操作中最麻烦的一步。

org.deepin.Session.service

[Service]
Type=dbus
BusName=org.deepin.Session
ExecStart=/usr/bin/dde-session --systemd-service
ExecStop=/usr/lib/libexec/dde-session-ctl --shutdown

在 dde-session-ctl 中是这么实现 shutdown 的:

if (isShutdown) {
// kill startdde-session or call login1
 QDBusInterface systemd("org.freedesktop.systemd1", "/org/freedesktop/systemd1", "org.freedesktop.systemd1.Manager");
qInfo() << systemd.call("StartUnit", "dde-session-shutdown.target", "replace-irreversibly");
return 0;
}

在 dde-session-ctl 中是这么实现 logout 的:

if (parser.isSet(logout)) {
org::deepin::Session session("org.deepin.Session", "/org/deepin/Session", QDBusConnection::sessionBus());
session.Logout();
return 0;
}

dde-session main.cpp

// 添加启动参数，表示这是通过 systemd 启动的。
QCommandLineOption systemd(QStringList{"d", "systemd-service", "wait for systemd services"});
parser.addOption(systemd);
parser.process(app);
if (parser.isSet(systemd)) {
return -1;
}
QDBusServiceWatcher *watcher = new QDBusServiceWatcher("org.deepin.Session", QDBusConnection::sessionBus(), QDBusServiceWatcher::WatchForUnregistration);
watcher->connect(watcher, &QDBusServiceWatcher::serviceUnregistered, [=] {
QDBusInterface systemdDBus("org.freedesktop.systemd1", "/org/freedesktop/systemd1", "org.freedesktop.systemd1.Manager");
qInfo() << systemdDBus.call("StartUnit", "dde-session-shutdown.service", "replace");
qApp->quit();
});
qInfo() << systemdDBus.call("StartUnit", "dde-session-x11.target", "replace");
}

dde-session-shutdown.service 只负责执行 dde-session-ctl --shutdown，用于启动 dde-session-shutdown.target。

dde-session-shutdown.service

[Service]
Type=oneshot
ExecStart=/usr/lib/libexec/dde-session-ctl --logout

通过 systemd 的接口启动了 dde-session-shutdown.target，从而启动了清理流程。

dde-session-shutdown.target 没有执行任何内容，仅仅是关联了一组服务，但是是冲突这些服务，因为这是启动的时候

在 dde-session-shutdown.target 中还关联了最重要的一个服务: dde-session-restart-dbus.service，这个服务是用来关闭 dbus.service 服务的，这样就可以保证 session 结束的时候，不会有 dbus 服务逃逸出去。

dde-session-restart-dbus.service

[Service]
Type=notify
ExecStart=/usr/lib/libexec/dde-session-ctl --restart-dbus

在 dde-session-ctl 中是这么实现 restart-dbus 的:

if (isRestartDBus) {
QDBusInterface systemd("org.freedesktop.systemd1", "/org/freedesktop/systemd1", "org.freedesktop.systemd1.Manager");
qInfo() << systemd.call("StopUnit", "dbus.service", "replace-irreversibly");
return 0;
}

复盘一下整个流程，在登录界面输入密码登录以后，lightdm 会启动 dde-session 作为 session 的入口，dde-session 会注册一个 org.deepin.Session 的 dbus 服务，并且会启动关联的 systemd 服务，启动一个 dde-session --systemd-service，在这个进程里，会启动 dde-session-x11.target，从而最终启动了 dde-session-manager.service，将原本的会话入口 startdde 启动了。

在 dde-session --systemd-service 会监听 org.deepin.Session 服务的存活，当服务不存在时，就会开始执行退出流程，从而启动了 dde-session-ctl --shutdown，在 dde-session-ctl 的帮助下，启动了 dde-session-shutdown.target，将所有启动的 dde 核心服务都冲突掉，从而完成了服务关闭，在最后阶段再将 dbus.service 服务停止，完成最终的清理。

还有一种退出模式，手动启动了 dde-session-shutdown.service 服务，也会触发完成的退出流程，dde-session-shutdown.service 会利用 dde-session-ctl --logout 将会话注销，从而触发上面的执行流程，完成会话与服务的关闭。

目前还有一些问题没有解决，没有创建独立的 systemd.slice 和 systemd.scope，这可以帮助 dde 细致的划分和管理自己的子 services，退出 dbus.service 的手段非常黑，而且 dbus 服务的程序由于图形服务也已经结束了，导致成片的 X11 Error。这些都是要解决的。

下一步准备写几个 service，用来代替 startdde 的组件启动，比如 kwin、dde-desktop、dde-dock 和 xdg-autostart 等。

就目前的情况来看，任重而道远。

原文链接：https://blog.justforlxz.com/2021/12/29/Starting-sessions-with-systemd-part-2/

Starting sessions with systemd part 2

justforlxz — Wed, 29 Dec 2021 13:09:07 +0000

接着上一篇文章 Starting sessions with systemd，这篇文章主要讲解一下具体的实现。

https://github.com/linuxdeepin/dde-session 已经包含了所有的文件和提交。

上面文章说过，为了让 dde 使用 systemd –user 来关系服务，我提供了一组服务：

dde-session-initialized.target
dde-session-manager.service
dde-session-manager.target
dde-session-pre.target
dde-session-restart-dbus.service
dde-session-shutdown.service
dde-session-shutdown.target
dde-session.target
dde-session-x11-services-ready.target
dde-session-x11-services.target
dde-session-x11.target
org.deepin.Session.service

lightdm 在认证通过以后，会启动 dde-session 进程，dde-session 会通过 systemd 的 dbus 启动 org.deepin.Session.service。

在 org.deepin.Session.service 中会执行 dde-session-ctl --systemd-service，启动 dde-session-x11.target.

dde-session-x11.target 关联了所有初始化的服务，systemd 会帮助自动运行这些服务，并且最终会运行到 dde-session-manager.service 上。

dde-session-manager.service

[Service]
Type=simple
ExecStart=/usr/bin/startdde
ExecStopPost=/usr/lib/libexec/dde-session-ctl --logout

org.deepin.Session.service

[Service]
Type=dbus
BusName=org.deepin.Session
ExecStart=/usr/bin/dde-session --systemd-service
ExecStop=/usr/lib/libexec/dde-session-ctl --shutdown

在 dde-session-ctl 中是这么实现 shutdown 的:

if (isShutdown) {
 // kill startdde-session or call login1
 QDBusInterface systemd("org.freedesktop.systemd1", "/org/freedesktop/systemd1", "org.freedesktop.systemd1.Manager");
 qInfo() << systemd.call("StartUnit", "dde-session-shutdown.target", "replace-irreversibly");
 return 0;
}

在 dde-session-ctl 中是这么实现 logout 的:

if (parser.isSet(logout)) {
 org::deepin::Session session("org.deepin.Session", "/org/deepin/Session", QDBusConnection::sessionBus());
 session.Logout();

 return 0;
}

dde-session main.cpp

// 添加启动参数，表示这是通过 systemd 启动的。
QCommandLineOption systemd(QStringList{"d", "systemd-service", "wait for systemd services"});
parser.addOption(systemd);
parser.process(app);

if (parser.isSet(systemd)) {
 return -1;
}

QDBusServiceWatcher *watcher = new QDBusServiceWatcher("org.deepin.Session", QDBusConnection::sessionBus(), QDBusServiceWatcher::WatchForUnregistration);
 watcher->connect(watcher, &QDBusServiceWatcher::serviceUnregistered, [=] {
 QDBusInterface systemdDBus("org.freedesktop.systemd1", "/org/freedesktop/systemd1", "org.freedesktop.systemd1.Manager");
 qInfo() << systemdDBus.call("StartUnit", "dde-session-shutdown.service", "replace");
 qApp->quit();
 });
 qInfo() << systemdDBus.call("StartUnit", "dde-session-x11.target", "replace");
}

dde-session-shutdown.service 只负责执行 dde-session-ctl --shutdown，用于启动 dde-session-shutdown.target。

dde-session-shutdown.service

[Service]
Type=oneshot
ExecStart=/usr/lib/libexec/dde-session-ctl --logout

通过 systemd 的接口启动了 dde-session-shutdown.target，从而启动了清理流程。

dde-session-shutdown.target 没有执行任何内容，仅仅是关联了一组服务，但是是冲突这些服务，因为这是启动的时候

dde-session-restart-dbus.service

[Service]
Type=notify
ExecStart=/usr/lib/libexec/dde-session-ctl --restart-dbus

在 dde-session-ctl 中是这么实现 restart-dbus 的:

if (isRestartDBus) {
 QDBusInterface systemd("org.freedesktop.systemd1", "/org/freedesktop/systemd1", "org.freedesktop.systemd1.Manager");
 qInfo() << systemd.call("StopUnit", "dbus.service", "replace-irreversibly");
 return 0;
}

下一步准备写几个 service，用来代替 startdde 的组件启动，比如 kwin、dde-desktop、dde-dock 和 xdg-autostart 等。

就目前的情况来看，任重而道远。

Starting sessions with systemd part 1

deepin 社区官方博客 — Sat, 25 Dec 2021 22:00:53 +0000

DDE 现在正在做 Wayland 的支持，所以我们需要对目前的桌面环境结构进行调整，考虑到 GNOME 和 KDE 都已经使用 systemd 来管理 session，我认为 deepin 团队也可以考虑这一步了。

为什么需要 systemd？

目前 systemd 作为事实上胜利的 init 进程，它现在负责的功能已经越来越多了，支持但不限于：udev、sleep/hibernate/suspend、dbus、services 等。现在越来越多的程序也开始使用 systemd 管理后台服务。

不使用 systemd 来管理 session 会有什么问题吗？

存在一个进程逃逸问题，不过这个问题与是否采用 systemd 管理 session 没有太大关系。

我先来简单介绍一下目前 DDE 的工作模型：

首先，DDE 使用 LightDM 作为显示服务器（Display Manager），DDE 提供了 lightdm-deepin-greeter 作为登录界面，greeter 可以通过调用 LightDM 的 api 进行 linux-pam 的认证。

当认证通过后，LightDM 会启动一个会话（Session），之后运行的程序都将是以登录的用户身份启动，然后 systemd --user 进程会被启动，同时 dbus-daemon 也会启动，之后 LightDM 会启动 startdde。

此时就开始执行到 DDE 的初始化阶段，startdde 会启动 dde-session-daemon 和 DDE 的核心组件，之后就并行启动 autostart 中的 desktop 文件。

startdde 目前的流程本身没有问题，问题出在 systemd 接管了 dbus，并且从 systemd 226 版本开始，/etc/pam.d/system-login 默认配置中的 pam_systemd 模块会在用户首次登录的时候, 自动运行一个 systemd --user 实例。只要用户还有会话存在，这个进程就不会退出；用户所有会话退出时，进程将会被销毁。当#随系统自动启动 systemd 用户实例启用时, 这个用户实例将在系统启动时加载，并且不会被销毁。

systemd --user 实例是针对每个用户处理的，而不是针对会话。这样做的原理是用户服务处理的大部分资源，像 socket 或状态文件是针对每个用户的（存活于用户的主目录下）而不是会话。这意味着所有的用户服务是独立于会话之外运行的。最终，我们得出结论：基于会话运行的程序可能会导致用户服务中断。systemd 处理用户会话的方式是非常生硬的（pretty much in flux）。

那么问题就来了，上面说了，systemd 接管了 dbus 服务，通过 dbus 启动的程序会在 dbus.service 下面，成为它的子进程，而 systemd --user 在有用户其它登录的会话存在时，并不会停止 systemd --user，所以 dbus.service 也不会停止。但是 dde 的会话已经完成注销了，但是通过 dde 启动的程序却没有被退出，从而导致了程序逃逸。

解决方案？

如果只是想解决逃逸问题，那么想一个办法，在 session 停止的时候，主动把 dbus.service 服务停掉其实就可以解决了，但是我们想要利用 systemd 的自动依赖解决，这样就不用重复造一点点小轮子了。

那么需要怎么修改才能符合桌面环境的要求？

GNOME 和 KDE 现在已经完成了 systemd session 的工作，我们可以在这两个老大哥身上学习。

提供了一个新的会话入口点 gnome-session-systemd。这需要一个参数，即开始会话的单元（通常是 .target 单元）。它将执行一些清理功能，初始化 systemd 环境，然后启动单元并等待它停止。会话通过修改它们的 Exec 行并删除 RequiredComponents 来选择以这种方式启动。

XDG autostart 现在 systemd 提供了一个 wrapper，可以自动生成出 service 单元，所以功能可以复用。

在 systemd 管理的系统上，每个用户都被分配了一个 user-x.slice (systemd.slice(5)),并且用户的会话将在 session-Y.scope (systemd.scope(5)) 中运行。您还可以在主机上看到一些其它用户特定的单元，包括 user@x.service,它是用户的 systemd 实例。这是用户的一个单独的 systemd 进程，如果用户不再登录，它将再次关闭。

随着 systemd 的移动，不仅 DBus 激活的应用程序和服务，您的整个会话现在都使用用户的 systemd 实例启动。这有一些副作用，起初可能看起来很奇怪。例如，之前提到的 session-Y.scope 曾经包含 200 多个进程，现在减少到仅 4 个进程。另一个副作用是更难理解进程属于哪个会话（这与许多服务相关）或者 ps 将不再显示 tty。

但是根据 GNOME blog 的文章说明，这些副作用已经被处理了。GNOME会话仍然始终绑定到session-Y.scope（例如，使用 loginctl kill-session 继续可靠地工作）。

查看了 GNOME 提供的 dbus 服务单元文件，最终明白了 GNOME 是怎么做到防止 dbus 程序逃逸的，其实操作非常简单，就是提供了一个 gnome-session-shutdown.target，在这个 target 里关联了 gnome-sessino-restart-dbus.service，里面执行的是 gnome-session-ctl --restart-dbus，其实就是通过 DBus 调用了 systemd --user 的 dbus 方法，将 dbus.service 给停掉了。（- - |）

改造方案

既然了解了前因后果，那么我们可以着手改造 DDE 了。

还需要补充一个知识，会话启动以后，会有一个进程作为会话的入口，会话所有的程序都是从这个入口开始启动的，这个入口就是 startdde。

我们既然希望利用 systemd 的服务来启动，并且帮助我们自动解决依赖，但是拆分项目目前压力比较大，我们还计划重写一部分后端功能，可以在重写时进行调整。

启动入口

首先我们需要创建一系列的 service 和 target 文件。

dde-session-initialized.target
dde-session-manager.service
dde-session-manager.target
dde-session-pre.target
dde-session-restart-dbus.service
dde-session-shutdown.service
dde-session-shutdown.target
dde-session.target
dde-session-x11-services-ready.target
dde-session-x11-services.target
dde-session-x11.target
org.deepin.Session.service

看起来非常的多，不用担心，他们都有各自的作用，你可以认为这是将生命周期在 systemd 实现了。

由于 systemd 会帮助我们自动完成依赖解析，那么我们只需要保留一个入口服务，其它服务都禁止手动启动即可。

我选择使用 dde-session-x11.target 作为入口，因为未来 deepin 还要支持 wayland，那么在这里就区分开会比较方便一些，因为桌面环境的后续启动与使用什么图形服务没有太大关系。

根据文件名称就可以方便的了解到这些文件是在什么阶段被执行的。

退出时清理

创建的 dde-session-shutdown.target 用来关联所有退出时需要执行的 services。

清理 dbus.service

提供了一个 dde-session-restart-dbus.service 用来注销以后关闭 dbus.service，不要问，问就是没办法～。

在 dde-session-shutdown.target 中会关联这个服务，当用户的会话注销或者桌面环境服务出现问题时，就可以退出所有的 dbus.service。

当发现会话注销时，dde-session-manager.service 会执行退出，在服务关闭时启动 dde-session-shutdown.target，并且使用 replace-irreversibly 标记为不可撤销。

dde-session-shutdown.target 中又会清理 dbus.service 下的所有程序，这样就避免了服务可以通过 dbus 逃逸出会话。

架构模型

最终效果

可以看到 startdde 和它的进程树挂在 systemd 下面。

原本的位置现在只有一个占位的程序。

引用资料

https://blogs.gnome.org/benzea/2019/10/01/gnome-3-34-is-now-managed-using-systemd/

原文链接：https://blog.justforlxz.com/2021/12/25/Starting-sessions-with-systemd/

Starting sessions with systemd

justforlxz — Sat, 25 Dec 2021 14:00:53 +0000

DDE 现在正在做 Wayland 的支持，所以我们需要对目前的桌面环境结构进行调整，
考虑到 GNOME 和 KDE 都已经使用 systemd 来管理 session，我认为 deepin 团队也可以考虑这一步了。

为什么需要 systemd？

不使用 systemd 来管理 session 会有什么问题吗？

存在一个进程逃逸问题，不过这个问题与是否采用 systemd 管理 session 没有太大关系。

我先来简单介绍一下目前 DDE 的工作模型：

此时就开始执行到 DDE 的初始化阶段，startdde 会启动 dde-session-daemon 和 DDE 的核心组件，之后就并行启动 autostart 中的 desktop 文件。

systemd --user 实例是针对每个用户处理的，而不是针对会话。这样做的原理是用户服务处理的大部分资源，像 socket 或状态文件是针对每个用户的（存活于用户的主目录下）而不是会话。这意味着所有的用户服务是独立于会话之外运行的。最终，我们得出结论：基于会话运行的程序可能会导致用户服务中断。systemd 处理用户会话的方式是非常生硬的（pretty much in flux）。

那么问题就来了，上面说了，systemd 接管了 dbus 服务，通过 dbus 启动的程序会在 dbus.service 下面，成为它的子进程，而 systemd --user 在有用户其它登录的会话存在时，并不会停止 systemd --user，所以 dbus.service 也不会停止。但是 dde 的会话
已经完成注销了，但是通过 dde 启动的程序却没有被退出，从而导致了程序逃逸。

解决方案？

那么需要怎么修改才能符合桌面环境的要求？

GNOME 和 KDE 现在已经完成了 systemd session 的工作，我们可以在这两个老大哥身上学习。

提供了一个新的会话入口点 gnome-session-systemd。这需要一个参数，即开始会话的单元（通常是 .target 单元）。它将执行一些清理功能，初始化 systemd 环境，然后启动单元并等待它停止。会话通过修改它们的 Exec 行并删除 RequiredComponents 来选择以这种方式启动。

XDG autostart 现在 systemd 提供了一个 wrapper，可以自动生成出 service 单元，所以功能可以复用。

在 systemd 管理的系统上，每个用户都被分配了一个 user-x.slice (systemd.slice(5)),并且用户的会话将在 session-Y.scope (systemd.scope(5)) 中运行。您还可以在主机上看到一些其它用户特定的单元，包括 user@x.service,它是用户的 systemd 实例。这是用户的一个单独的 systemd 进程，如果用户不再登录，它将再次关闭。

随着 systemd 的移动，不仅 DBus 激活的应用程序和服务，您的整个会话现在都使用用户的 systemd 实例启动。这有一些副作用，起初可能看起来很奇怪。例如，之前提到的 session-Y.scope 曾经包含 200 多个进程，现在减少到仅 4 个进程。另一个副作用是更难理解进程属于哪个会话（这与许多服务相关）或者 ps 将不再显示 tty。

但是根据 GNOME blog 的文章说明，这些副作用已经被处理了。GNOME会话仍然始终绑定到session-Y.scope（例如，使用 loginctl kill-session 继续可靠地工作）。

查看了 GNOME 提供的 dbus 服务单元文件，最终明白了 GNOME 是怎么做到防止 dbus 程序逃逸的，其实操作非常简单，就是提供了一个 gnome-session-shutdown.target，在这个 target 里关联了 gnome-sessino-restart-dbus.service，里面执行的是 gnome-session-ctl --restart-dbus，
其实就是通过 DBus 调用了 systemd --user 的 dbus 方法，将 dbus.service 给停掉了。（- - |）

改造方案

既然了解了前因后果，那么我们可以着手改造 DDE 了。

还需要补充一个知识，会话启动以后，会有一个进程作为会话的入口，会话所有的程序都是从这个入口开始启动的，这个入口就是 startdde。

启动入口

首先我们需要创建一系列的 service 和 target 文件。

dde-session-initialized.target
dde-session-manager.service
dde-session-manager.target
dde-session-pre.target
dde-session-restart-dbus.service
dde-session-shutdown.service
dde-session-shutdown.target
dde-session.target
dde-session-x11-services-ready.target
dde-session-x11-services.target
dde-session-x11.target
org.deepin.Session.service

看起来非常的多，不用担心，他们都有各自的作用，你可以认为这是将生命周期在 systemd 实现了。

由于 systemd 会帮助我们自动完成依赖解析，那么我们只需要保留一个入口服务，其它服务都禁止手动启动即可。

根据文件名称就可以方便的了解到这些文件是在什么阶段被执行的。

退出时清理

创建的 dde-session-shutdown.target 用来关联所有退出时需要执行的 services。

清理 dbus.service

提供了一个 dde-session-restart-dbus.service 用来注销以后关闭 dbus.service，不要问，问就是没办法～。

在 dde-session-shutdown.target 中会关联这个服务，当用户的会话注销或者桌面环境服务出现问题时，就可以退出所有的 dbus.service。

当发现会话注销时，dde-session-manager.service 会执行退出，在服务关闭时启动 dde-session-shutdown.target，并且使用 replace-irreversibly 标记为不可撤销。

dde-session-shutdown.target 中又会清理 dbus.service 下的所有程序，这样就避免了服务可以通过 dbus 逃逸出会话。

架构模型

最终效果

可以看到 startdde 和它的进程树挂在 systemd 下面。

原本的位置现在只有一个占位的程序。

引用资料

https://blogs.gnome.org/benzea/2019/10/01/gnome-3-34-is-now-managed-using-systemd/

CSS浮动笔记

justforlxz — Sat, 07 Aug 2021 03:02:20 +0000

DOM文档排版的特点

块级元素只能垂直排版，行内元素只能水平排版。

块级元素可以设置宽高属性，行内元素没有宽高属性，只能被内部元素撑起来，水平放置不下时会换行继续排版。

CSS 浮动

浮动就是让文档脱离文档流，在父元素内部可以移动到指定位置。

浮动的元素可以设置宽高，像块级元素一样，又向行内元素一样可以水平排版。

<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>元素的浮动</title>
<style type="text/css">
/*定义父元素的样式*/
.father {
 background: #ccc;
 border: 1px dashed #999;
}

/*定义 box01、 box02、 box03 三个盒子的样式*/
.box01, .box02, .box03 {
 height: 50px;
 width: 50px;
 background: #FF9;
 border: 1px solid #F33;
 margin: 15px;
 padding: 0px 10px;
}

/*定义段落文本的样式*/
p {
 background: #FCF;
 border: 1px dashed #F33;
 padding: 0px 10px;
}
</style>
<style>
.box01, .box02, .box03 {
 float: left;
}
</style>
</head>
<body>
 <div class="father">
 <div class="box01">box01</div>
 <div class="box02">box02</div>
 <div class="box03">box03</div>
 </div>
 <p>12</p>
<!--不定义float属性，float属性值都为其默认值 none-->
</body>
</html>

运行后，box01、box02、box03 及段落文本从上到下一一罗列。可见如果不对元素设置浮动，则该元素及其内部的子元素将按照标准文档流的样式显示，即块元素占据页面整行。

接下来以 box01 为设置对象，对其应用左浮动样式，在 head 的 style 标签下添加新的 style 标签，具体CSS代码如下：

.box01 {
 float: left;
}

可以看到 box01 已经脱离了文档流，接下来为 box02 和 box03 设置左浮动：

.box02 {
 float: left;
}

.box03 {
 float: left;
}

上述代码运行后，box01、 box02、 box03 三个盒子排列在同一行，同时，周围的段落文本将环绕盒子，出现了图文混排的网页效果。

CSS 浮动清除

由于浮动元素不占用原文档流的位置，使用浮动时会影响后面相邻的固定元素。

CSS 提供了 clear 属性，可以清除掉浮动元素。

clear 有三个属性值：

left ：不允许左侧有浮动元素(清除左侧浮动的影响)

right ：不允许右侧有浮动元素(清除右侧浮动的影响)

both ：同时清除左右两侧浮动的影响

浮动清除存在一个问题，浮动清除本质上处理的是左右元素，如果父元素内所有的元素都浮动了，此时因为文档流中没有其他元素可以在内部撑起父元素的高度，父元素此时会坍缩为 0 高度。

方法一：使用空标记清除浮动

在浮动元素之后添加空标记，并对该标记应用 clear:both 样式，可清除元素浮动所产生的影响，这个空标记可以为 <div> 、 <p> 、 <hr /> 等任何标记。

需要注意的是，上述方法虽然可以清除浮动，但是在无形中增加了毫无意义的结构元素(空标记)，因此在实际工作中不建议使用。

(空标记)因此在实际工作中不建议使用。

<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>空标记清除浮动</title>
<style type="text/css">
/*没有给父元素定义高度*/
.father {
 background: #ccc;
 border: lpx dashed #999;
}

/*定义box01、box02、box03三个盒子左浮动*/
.box01, .box02, .box03 {
 height: 50px;
 line-height: 50px;
 background: #f9c;
 border:1px dashed 999;
 margin: 15px;
 padding: 0px 10px;
 float: left;
}

/*对空标记应用clear:both;*/
.box04 {
 clear: both;
}
</style>
</head>
<body>
 <div class="father">
 <div class="box01">box01</div>
 <div class="box02">box02</div>
 <div class="box03">box03</div>
 <div class="box04"></div>
 <!--在浮动元素后添加空标记-->
 </div>
</body>
</html>

方法二：使用 overflow 属性清除浮动

对元素应用 overflow: hidden; 也可以清除浮动对该元素的影响，该方法弥补了空标记清除浮动的不足。

对父元素应用 overflow: hidden; 样式来清除子元素浮动对父元素的影响。

父元素又被其子元素撑开了，即子元素浮动对父元素的影响已经不存在。

<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>overflow属性清除浮动</title>
<style type="text/css">

/*没有给父元素定义高度*/
.father {
 background: #ccc;
 border: 1px dashed #999;
 /*对父元素应用overflow:hidden;*/
 overflow: hidden;
}

/*定义box01、box02、box03三个盒子左浮动*/
.box01, .box02, .box03 {
 height: 50px;
 line-height: 50px;
 background: #f9c;
 border: 1px dashed #999;
 margin: 15px;
 padding: 0px 10px;
 float: left;
}
</style>
</head>
<body>
 <div class="father">
 <div class="box01">box01</div>
 <div class="box02">box02</div>
 <div class="box03">box03</div>
 </div>
</body>
</html>

方法三: 使用 after 伪对象清除浮动

使用 after 伪对象也可以清除浮动，但是该方法只适用于 IE8 及以上版本浏览器和其他非 IE 浏览器。

另外，使用 after 伪对象清除浮动时需要注意：

(1) 必须为需要清除浮动的元素伪对象设置 height: (); 样式，否则该元素会比其实际高度高出若干像素。

(2) 必须在伪对象中设置 content 属性，属性值可以为空，如 content：" "; 。

<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>使用after伪对象清除浮动</title>
<style type="text/css">

/*没有给父元素定义高度*/
.father {
background: #ccc;
border: 1px dashed #999;
}

/*对父元素应用after伪对象样式*/
.father:after {
 display: block;
 clear: both;
 content:" ";
 visibility: hidden;
 height: 0;
}

/*定义box01、box02、box03三个盒子左浮动*/
.box01, .box02, .box03 {
 height: 50px;
 line-height: 50px;
 background: #f9c;
 border: 1px dashed #999;
 margin: 15px;
 padding: 0px 10px;
 float: left;
}

</style>
</head>
<body>
 <div class="father">
 <div class="box01">box01</div>
 <div class="box02">box02</div>
 <div class="box03">box03</div>
 </div>
</body>
</html>

翻译：记 2019 年的 X.org 开发者研讨会 - emersion

deepin 社区官方博客 — Thu, 11 Mar 2021 03:03:00 +0000

原文：https://emersion.fr/blog/2019/xdc2019-wrap-up

> XDC 2019 wrap-up 2019-10-10

这篇文章是我从加拿大蒙特利尔飞往赫尔辛基的路上写的，我刚参加完 X.Org 的开发者研讨会。从去年西班牙那次会议以来，这是我第二次参加 XDC（译者注：X.Org Developer’s Conference）。

今年的研讨会非常的给力。我遇到了很多一起工作过的同志，他们来自四面八方的各个组织和项目。会议内容也很牛，我会尝试总结一下这次讨论的一些事情。

libliftoff

前一阵子，我搞了一个新项目，名字叫 libliftoff。它是我在这次会议上的亮点，所以接下来我会详细的介绍它。带着问题往下看：“libliftoff 是用来解决什么问题的呢？”

libliftoff 是什么

它是一个合成器的中间层，负责从 clients 中获取 buffers，把它们绘制在一个独立的 buffer 上，并把这个 buffer 显示到屏幕上。假设我现在打开了一个“文本编辑器”和一个“终端”，合成器会把它们的窗口 buffer 复制到屏幕的 buffer 上，一般是用 OpenGL 做这个事。

不过，复制 buffers 的操作很浪费资源，因为它会做很多事情，比如：它总是进行 alpha 混合、在不同格式之间转换、让渲染引擎一直干活（注：GPU 在执行 OpenGL/Vulkan 的命令）等等，这些操作不仅占用时间，而且也会增加耗电量。

为了改善性能，许多 GPU 都提供了硬件实现的“叠加平面（planes）”支持（下文直接称为“叠加平面”）。“叠加平面”可以作为显示引擎负责合成工作，这种行为称为直接显示，可以避免全让合成器做复制 buffers 的活。

在 Android 上，硬件“叠加平面”在“Hardware Composer”组件中用的很广。许多 Wayland 合成器也会为光标使用“叠加平面”，但是用在其它场景的情况还是很少见。Weston（译者注：一个 Wayland 合成器）是仅有的使用“叠加平面”的合成器之一。

使用“叠加平面”并不是一件容易的事情，它有一些限制，比如：不支持 Alpha 通道、不是任意的 buffer 都可以用。虽然这些限制往往会让人觉得很扯淡，但它是由硬件特性决定的。举个例子：对于某些格式的 buffers，Intel 的硬件只能将其放在“叠加平面”的偶数坐标位置、某些 buffers 是在内存上分配的，“叠加平面”干脆就不支持这一类的 buffer、另外，显示设备一般都有带宽限制，在“叠加平面”上使用过大的 buffer 时会失败、某些 ARM 设备上，多个“叠加平面”之间不支持重叠。

目前为止，关于硬件的这些限制信息，合成器程序还查询不了，因为硬件之间的差异性很大，所以很难设计一个能查询硬件限制信息的 API，甚至在某些新出 GPU 上还会有更奇怪的限制。唯一的方法是搞一些前置工作，用它做一些尝试性的使用。

因此，设计和实现一个能有效的使用“叠加平面”的代码是一个相当复杂的事情。我一直在想，共享这些代码，是不是会对合成器使用“叠加平面”有所帮助，于是我就奔着这个目标设计了 libliftoff。

libliftoff 的研讨会

我在 XDC 搞了一个研讨会，讨论关于 libliftoff 的事情，目的是把合成器和驱动专家凑一块，一起商量如何才让合成器有效的用上“叠加平面”。

libliftoff 的受欢迎程度让我很惊讶，连桌子附近都坐满了人：

在合成器这边，有 wlroots 团队的人（Drew DeVault, Scott Anderson 和我自己），KDE 的 Roman Gilg，Weston 的 Daniel Stone，还有 X server 的 Keith Packard。
在驱动这边，有很多来自于不同厂商的开发者：有 AMD、Arm、Google、Nvidia、Qualcomm 等等。

大家貌似都很兴奋，为 libliftoff 提了很多宝贵的意见。我在此感谢所有参与研讨会的人！

短期的计划是，让 libliftoff 为合成器提供能实际使用的功能（实验性的），不过有个事我还需要弄清楚，那就是应该怎么样支持多个 output：因为每个 output 都有自己的时序，所以，如何将“叠加平面”从一个 output 迁移到另一个 output 是一件很难搞的问题。最终，如果能实现这样的功能就完美了：为每一个图层分配一个优先级，并把那些频繁在别的图层之前更新的图层放在同一个“叠加平面”上。

另外也讨论了一些长期计划。

首先，我们想搞定一个跟内存相关的问题：clients 往往会在内存上分配 buffer，这些 buffer 没法直接用在“叠加平面”上。通常，合成器都会给一些提示信息：“你现在正在使用 Y_TILED，所以我不能将你用在“叠加平面”上，但是如果你能使用 X_TILED 我就能把你用在“叠加平面”上”，这样 client 就可以决定切换它的 buffer 格式。我大概在一年前给 Wayland 提了一个补丁，这个补丁新增的信息能被 libliftoff 识别出来，在这种情况下，合成器可以把这个信息转发给 clients。

接下来是关于内核 API 的问题，现在只有一个办法能让我们知道是否可以使用“叠加平面”，那就是用 atomic 相关的 test 接口测试（译者注：atomic 是 DRM 提供的一系列原子操作接口，支持事务），这个做法相当的不清真，因为我们必须得遍历尝试多个组合条件，基本上是暴力求解。除此之外，比较好的做法都要跟具体的硬件相关。

为了搞定这个问题，我们必须让内核提供更多的信息，但是因为不同硬件的差异性很大，设计一个足够通用的 API 将是一个很蛋疼的事情，另一个解决方案是在 libliftoff 中添加特定厂商的插件，允许每个驱动添加自己的代码，以此更好的匹配自己的硬件。目前来说，貌似这是最好的方案了。

这是本次讨论的总结(PPT)：

视频：XDC 2019 - Day 3

Scott Anderson 也写了一些总结，是关于 Wayland 协议的一些想法的详细介绍。

分配器

在三年前的 XDC 上，Nvidia 的 James Jones 提出了这个分配器项目，用于解决 GBM/EGLStreams 现有的问题。今年，他做了一个关于 GBM、Nouveau 和 transitions 的新的分享。跟之前的提案相比，这个提案的目的是在现有 API 的基础上建立一种叫 transition 的机制。

视频：XDC 2019 - Day 2

transition 可以用来减少渲染引擎的带宽占用。某些 GPU 支持使用压缩的 buffer，与未压缩的 buffer 相比，GPU 可以在这些压缩后的 buffer 上直接执行 OpenGL/Vulkan 的操作，这样做效率很高。所以，我们应该在渲染时使用压缩后的 buffers。

不过，压缩后的 buffers 不能直接用在“叠加平面”上，需要先将它们解压才能使用，有一个方法是把它解压为一个新的 buffer，但是这样需要复制数据，速度会很慢。

在某些 GPU 上有个更好的方法，它们支持在“叠加平面”中直接解压 buffer。这指的是：当一个 Wayland client 在压缩后的 buffer 上渲染，如果这个 buffer 可以在“叠加平面”中解压，并且之后可以直接使用它，那我们就将这种“buffer 就地解压的程序”称为 transition。

之后我们在一个研讨会中继续探讨 transitions，讨论了应该在何时何地进行 transition 操作。想法一是：如果合成器准备把一个 buffer 用到“叠加平面”中，那就在合成器中做这个事，可以用 libliftoff 判断什么时候应该使用 transition。另一个想法是：在 client 把 buffer 提交给合成器之前做这个事，client 需要从合成器那获取一个信息，以便知道应该什么时候执行操作（这就是我之前提到的那个 Wayland 协议的补丁可以做的事情）。

这是这次研讨会的总结：

视频：XDC 2019 - Day 3

可变刷新率（VRR）

AMD 的 Harry Wentland 搞了一个关于“自适应同步”（DisplayPort 的技术）、“可变刷新率”（HDMI 的技术）和“FreeSync”（AMD 的技术）的研讨会。所有这些技术都是为了适配屏幕的功能，允许它从“固定为 60Hz”的模式变成“可以稍微等待下一帧”的模式（译者注：动态刷新率的模式）。

视频：XDC 2019 - Day 2

这东西的主要使用场景是游戏应用。游戏通常是用动态刷新率的方式更新画面（依赖于场景的复杂度），下一帧可以更快也可以更慢。游戏还希望能降低延迟，即避免渲染到在屏幕上显示的时间差过长。

在屏幕固定刷新率的情况下，如果有一帧的渲染用时稍微长了一点，它错过了显示器的刷新时机，这样就会导致这一帧的显示有些滞后，而 VRR 则允许增加屏幕刷新时的等待时间，以免丢帧。

另一种场景是视频播放。视频有固定的帧率，但是通常会与屏幕的刷新率不同，视频播放器需要用帧插值的方式，才能适应屏幕的刷新率，而 VRR 则允许降低刷新率以匹配能完美播放视频的时序。

屏幕内容通常都是处于静止状态，在这种情况下，VRR 还可以降低电量消耗。比如用户在使用文本编辑器时，完全不需要 60FPS，这时候合成器可以降低屏幕的刷新率。

游戏的使用场景比较简单，合成器可以比 deadline 稍微晚一点点提交帧，硬件可以搞定这种情况。其它场景需要做更多的工作，要想把 VRR 用在视频播放器上，我们需要某种定时提交帧的 API。要想用 VRR 做节能，合成器要能支持帧率改变时的平滑过渡，否则屏幕会有闪烁问题（这是支持 VRR 功能的屏幕的限制）。

在我看来，我们目前应该把精力放在 Wayland 协议对游戏场景的支持上，因为搞其它两种场景需要做的事情太多了，它们不仅需要更多的新 API（内核和 Wayland 的都需要），还需要做很多的实验工作。

Chamelium

我在 Intel 实习期间，参与了一个叫 Chamelium 的项目，它是一个基础的屏幕模拟器，你可以通过网络向它发送命令，它已经被用在了 ChromeOS 的 i915 显卡环境的 CI 服务中。

我搞了一个关于这个项目以及我在项目内的工作的研讨会：

视频：XDC 2019 - Day 3

除了这三个主题，我们还讨论了很多其它的东西，但是不能全塞到这一篇博客中讲，所以就说到这吧。感谢所有参加 XDC 的人，感谢 Mark Filion 组织了这次活动，还要感谢所有赞助商，没有你们的赞助就不会有的这次活动！

如何给Arch打一个包

justforlxz — Thu, 04 Mar 2021 03:23:42 +0000

Arch 使用的是 pacman 包管理器，包格式是 tar.zst。Arch 提供了一些工具用于创建 tar.zst 包，首先需要安装 base-devel 包和 devtools 包。

pacman -S base-devel devtools

Arch 的打包流程是这样的，要先写一个 PKGBUILD 文件，这个文件描述了构建一个包所需的全部信息，如从哪里下载源码，依赖有哪些，构建的版本是多少，如何进行构建等。

PKGBUILD

一个基本的 PKGBUILD 格式如下：

# Maintainer: justforlxz <justforlxz@gmail.com>

pkgname=dtkcore-git
pkgver=5.4.0.r1.ge7e7a99
pkgrel=1
pkgdesc='DTK core modules'
arch=('x86_64')
url="https://github.com/linuxdeepin/dtkcore"
license=('LGPL3')
depends=('dconf' 'deepin-desktop-base-git' 'python' 'gsettings-qt' 'lshw')
makedepends=('git' 'qt5-tools' 'gtest')
conflicts=('dtkcore')
provides=('dtkcore')
groups=('deepin-git')
source=("$pkgname::git://github.com/linuxdeepin/dtkcore.git")
sha512sums=('SKIP')

pkgver() {
 cd $pkgname
 git describe --long --tags | sed 's/\([^-]*-g\)/r\1/;s/-/./g'
}

build() {
 cd $pkgname
 qmake-qt5 PREFIX=/usr DTK_VERSION=$pkgver LIB_INSTALL_DIR=/usr/lib
 make
}

package() {
 cd $pkgname
 make INSTALL_ROOT="$pkgdir" install
}

以 dtkcore 为例，整个配置文件十分清晰明了，一看就知道构建工具是如何一步步制作出一个包的。

将配置文件保存到目录里，以 PKGBUILD 命名，然后执行 makepkg。

makepkg 是用于执行 PKGBUILD 文件的工具，它根据文件中的描述，进行包的构建。

如何提交一个包到 aur

当你希望自己打的包可以被别人使用的时候，一般都会请求上传到官方仓库，但是进入官方仓库的流程异常繁琐，而且对贡献者的要求会比较高。Arch 提供了一个用户仓库，供用户自由分享配置文件，只需要下载配置文件，在本机打包就可以了。

根据 aur 的贡献指南，我们可以很轻松的上传自己的配置文件，并借用yay等aur工具自动下载和构建软件包。

用户可以通过 Arch User Repository 分享 PKGBUILD。AUR 中不包含任何二进制包，仅包含用户上传的 PKGBUILD，供其他用户下载使用。所有软件包都是非官方的，使用风险自担。

提交aur之前，需要先了解一下 aur 的一些要求，Rules of submission 提供了一些规则，只要我们按照规则来，就可以上传和维护我们自己的包。

首先需要去 aur官网注册一个账号，并上传自己的 ssh key 我们通过克隆一个新的仓库来作为上传的方式。

git clone ssh://aur@aur.archlinux.org/<pkgname>.git

以dtkcore为例，克隆的时候把pkgname改成dtkcore。

git clone ssh://aur@aur.archlinux.org/dtkcore.git

如果是第一次创建，会提示你克隆的一个空仓库。

把 PKGBUILD 文件复制到克隆的目录，然后执行 makepkg --printsrcinfo > .SRCINFO 创建一个软件包信息，将 .SRCINFO 和 PKGBUILD 文件都添加到 git 中，然后提交 commit 信息，推送到服务器。

注意：如果您忘记在首次提交中包含 .SRCINFO，您可以使用 rebasing with –root 或是 filtering the tree 使得 AUR 接受您的第一次推送

提示：为了保持工作目录和提交尽可能的干净，可以创建 gitignore 文件来排除所有文件，然后再按需添加文件。

参考资料：

https://wiki.archlinux.org/index.php/PKGBUILD

2020 Review

justforlxz — Fri, 26 Feb 2021 14:51:45 +0000

2020

拖了这么久才更新博客，想必大家都在 2020 年过的挺不好的，年初武汉的疫情打了全国一个措不及防，甚至已经一整年了，全球疫情还是十分紧张。截止到 2021 年 2 月 26 日，全球每日新增仍然有30 多万，而且全球累计死亡已有 250 万人之多。

疫情

生命是如此的脆弱。有些时候和朋友们一起吃饭，会说起一月份时大家是如何 逃离 武汉的，在家隔离又多了哪些事情，我们活着是多么的不容易。虽然人类已经可以生产 5 纳米的芯片了，但是就如同我们对这个宇宙的认知一样，几百亿光年外任我们看，可太阳系内有什么我们都不知道，甚至在地球上还有很多我们未知的东西。

计划失误

2020 年我的计划几乎没有一件事是完成的，我计划应该一整年掌握 TypeScript 和 web 开发，并开发自己的blog系统，但是方案被我推到重来了三次，我就没耐心继续开发了，只完成了基本的 md 文件编译和服务器渲染就暂停了。计划阅读 《1984》 、 《TensorFlow》 和 《TypeScript实战》 ，然而只有 《TypeScript实战》阅读完了，剩余两本书我则是只看了一丢丢，看来只能放到 2021 年读完了。

她

在 2019Review 的文章里，我提到了我遇到了生命中的那个她，而 2020 年，我和她 结婚 啦。

在家隔离的日子里，有她陪伴着我，虽然老家的人都挺敌视从武汉回来的我，但是大门一关我谁也看不到，眼不见心不烦，在家一块搓麻将挺好的，还一起练 (zao) 习 (ta)了厨艺，朋友圈做饭比赛第一名。

学习

虽然我读书拉后了，但是我的英语 坚持 了下来，我使用多邻国进行英语和日语的学习，已经坚持快6个月了，需要继续加油努力，争取早日把学校里拉下的英语 补 回来。

工作

2020 年最大的收益可能是创建了 deepin-git 的仓库，提供了 dde 所有组件在 arch 上的git版，并且还成功申请到了 archlinuxcn 的贡献者。

文章

2020 年一共水了18篇文章。

12-23 ccls
11-17 Qt多线程
09-17 deepin-wine中文乱码
09-08 使用rEFInd来安全启动系统
09-06 deepin git version
09-03 使用VSCode远程开发DDE
08-06 在ArchLinux上开发startdde
07-27 use github action to check dde-launcher
07-21 使用perf工具分析程序性能
06-16 CTest & QTest/GTest
06-15 CPP项目的一些坑
06-15 使用inquirer提供交互式git commit
06-01 vue-router路由复用后页面没有刷新
05-31 vue3升级遇到的坑
02-01 JavaScript建造者模式
01-31 浅谈Javascript构造器模式
01-01 2019 Review
01-01 使用伪元素创建一个圆点

研究了 vscode 的插件，开发了一个 qmake 的插件原型，可以打开 dtk 等 qt pro 的项目，利用 bear 拦截 make 的编译信息，生成 ccls 需要的数据库，这样就可以为项目提供自动补全和语法检查等功能了。

写了一些关于远程开发的文章，也是利用 vscode 的远程功能，不得不说 vscode 真的可以说是宇宙第一编辑器了，让老牌的 vim 和 emacs 知道了什么叫易用性的力量。

展望

2021 年，不能松懈，今年要继续努力学习，努力提升自己。

在 2021 年里，我将会负责 deepin 的社区，由于前两年公司需要快速扩张，导致忽略了社区，现在我们的首要任务就是恢复社区，并让社区良性的自由发展，社区是我们的根本。

挖了很多坑，今年争取都填一下。

其他

又搬家了，找了一个一室一厅，开启了二人的小日子，过了年以后把狗子也带来了，现在天天早上起来打狗，晚上回来打狗。

我又给 肝疼3 氪了一个月卡，这次只忘了一天没登录，不然 30 块大洋又要白花了。

祝大家幸福安康，新年快乐！(^▽^)

deepin-wine中文乱码

justforlxz — Thu, 17 Sep 2020 08:32:12 +0000

众所周知，使用wine来运行windows下的一些软件是linux用户的常用操作，deepin为社区贡献了好几款中国用户必备的软件，例如QQ、微信、企业微信，以此来让更多的人无痛的切换到linux来。近年来value也一直在linux上布局，先后推出了steam主机和proton,前者是基于kvm和steam大屏幕模式的系统，而proton则是wine的分支，value提供了几组补丁用来提高性能和与Windows游戏的兼容性。

Arch上有非常方便的aur仓库，有很多用户都自己提交一些软件到aur上面，就有几个维护者将deepin打包的deepin wine和对应的软件包移植到Arch上面来，已经是很多人在Arch上面运行QQ和微信的首选方案。

但是使用的过程中我遇到了以下几个问题：

输入框中文乱码
在DDE桌面使用kwin的情况下最小化会卡死
KDE桌面环境无法使用deepin wine的程序

第二个问题比较特殊，因为dde在deepin和uos下运行的是fork版本的kwin,而Arch上运行的则是原版的kwin,一些操作代码并不具备，所以会出现一些奇葩的状况。

第三个问题则是xsettings的原因，在移植者的仓库有对应的issue讨论《KDE环境完全无法使用wine-tim》

第一个问题解决起来也比较简单，是因为缺少了宋体文件，从而无法正确的渲染中文字体。而比较奇葩的是，把方块复制再粘贴，就可以正确的渲染了。

解决的方法也很简单，把windows的的字体复制过来就可以了。由于版权的问题，没办法直接提供文件，需要各位自己复制了。

引用资料

https://github.com/wszqkzqk/deepin-wine-ubuntu/issues/136

使用rEFInd来安全启动系统

justforlxz — Tue, 08 Sep 2020 11:54:26 +0000

今年的七夕，我老婆给我买了一台surface laptop 2代，8G内存 + 256G存储版本，我也成功的用上了田牌的机器。

2020/09/17更新：不知道为啥，反正是开了对内核签名以后，哪怕是BIOS关闭了安全启动，仍然出现mkinitcpio会卡在autodetect上，无奈全部都删掉重来了，没有弄签名，希望各位看到本文章以后解决了这个问题能回复一下，谢谢。

surface默认是开启了安全启动(Microsoft签名)和bitlocker来保障设备和系统安全，我作为一个linux系统的开发者，当然是需要在surface上装一个linux了，但是前两年zccrs已经踩过坑了，linux不识别surface键盘，同样的触摸、网卡、声卡等设备也工作的不是很正常，本来以为我要开启远程开发的生活了，还特意写了一篇《使用VSCode远程开发DDE》，来给公司里有同样烦恼的人，让他们也感受一下远程开发的魅力。

苍天不负有心人，我成功的！

我成功的使用上了ArchLinux,并且工作的十分良好。这多亏了github上的一个组织linux-surface，有这么一些人，他们付出劳动来让手里的surface设备也用上linux,并且要和普通的x86兼容机一样工作，感谢他们的付出，也让我吃上了螃蟹，安装的过程我就不在这里详细说了，其实非常简单。

首先因为surface只有一个usb口，而键盘并不能工作，所以需要一个usb的扩展器。先按fn+f6进bios关闭掉安全启动，修改引导顺序为usb优先，之后就是正常的安装系统，但是不需要安装仓库里的内核，我们需要安装linux-surface提供的仓库里的内核。

这些都是非常正常的步骤，linux-surface提供了自己的仓库和内核，我们正常使用即可。

这里开始就是我研究了半天的内容， 开启安全模式!

首先我看了一下arch wiki上有关于安全启动的内容，写的挺详细的，就是看不懂。讲了各种的知识点，各种签名的方式，但是真正到我开始用的时候，我是一直失败的，失败的方式我就不说了，直接说我如何成功的。

首先我放弃了grub,一个原因是grub的安全启动我一直没有尝试成功，另外一个是我只有一个系统，没必要用grub。我换成了rEFInd来作为我的bootloader，首先安装rEFInd的引导。

yay -S refind shim-signed sbsigntools

sudo refind-install --shim /usr/share/shim-signed/shimx64.efi --localkeys

来解释一下上面两条明令。第一个是安装必要的软件包，refind是bootloader本体，shim-signed是aur里面的用于安全启动的包，shim提供了一种并行的安全启动验证功能，我们使用它来启动refind的efi,再通过refind的efi启动内核，达到终极套娃启动。sbsigntools是用于给文件签名的工具，我们安装完refind以后，refind会帮助我们生成一份默认的key,我们需要使用这个key来为内核进行签名。

在执行第二条明令以后，会有几次询问，都选择Y回车就行。

然后使用sbsigntools来对内核进行签名。

sudo sbsign --key /etc/refind.d/keys/refind_local.key --cert /etc/refind.d/keys/refind_local.crt --output /boot/vmlinuz-linux-surface /boot/vmlinuz-linux-surface

准备工作已经进行一半了，我们只需要写一下refind的配置文件，就可以启动了。

refind的配置文件有两个地方，一个是boot分区下面的refind_linux.conf，还有一个是在efi分区里的EFI/refind/refind.conf，我们需要修改的是后者。

默认配置文件都是注释的，其实我们全部删了就可以了，有需要修改的地方去看原始文件或者文档就行了。

添加一个menuentry，就可以启动系统了。

also_scan_dirs +,ArchFS/boot
dont_scan_dirs ESP:/EFI/boot,EFI/boot
dont_scan_files shim.efi,MokManager.efi,fbx64.efi,mmx64.efi,shimx64.efi
scan_all_linux_kernels false

menuentry "Arch Linux" {
 icon /EFI/refind/icons/os_arch.png
 volume 8B131F77-62D7-4B4A-82D4-B60D7ACA2F6C
 loader /ArchFS/boot/vmlinuz-linux-surface
 initrd /ArchFS/boot/intel-ucode.img
 initrd /ArchFS/boot/initramfs-linux-surface.img
 options "root=UUID=9f8f9556-8ec1-4feb-9519-435beac8376f rw rootflags=subvol=ArchFS loglevel=3 quiet add_efi_memmap"
 submenuentry "Boot using fallback initramfs" {
 initrd /ArchFS/boot/initramfs-linux-surface-fallback.img
 }
 submenuentry "Boot to terminal" {
 add_options "systemd.unit=multi-user.target"
 }
}

我用的是btrfs文件系统，所以配置文件有点罗嗦。解释一下上面的内容。

also_scan_dirs是指定扫描某个目录，因为我是btrfs文件系统，必须使用这个才能让refind扫描到内核文件，否则会无法启动。

dont_scan_dirs是跳过指定的目录，因为refind默认是会扫描所有的efi文件，我们自己提供了emnuentry,所以不需要让它扫描了。

dont_scan_files是跳过指定的文件，这里是防止其他目录出现对应的efi也被扫描到。

scan_all_linux_kernels是扫描所有linux内核，这样所有的内核就会出现在启动列表里，我们同样也是不需要的。

menuentry里面需要修改的地方有，volume是分区的partuuid,我因为这个uuid就测试了好几次，最后才反应过来不是filesystem uuid,要求的是partition uuid. 所有遇到ArchFS的地方都是不需要的，因为btrfs支持字卷，我的系统是在一个叫ArchFS的卷里面的，如果不是btrfs的文件系统，这个是不需要的，同样options里的rootflags选项也是不需要的，这是传递给内核的参数，让内核可以正确的加载根分区。

这样就算完工了，重启系统，然后进bios里把安全启动改成Microsoft & 3rd party CA，然后重新启动。

当第一次加载rEFInd的时候，因为我们的证书是才生成的，主板并没有存储对应的签名，rEFInd会启动mmx64.efi来让我们加载证书，证书的位置在/etc/refind.d/keys下，选择refind_local.cer导入，然后选择重启，重新进入系统就可以了。

导入证书这部分我其实不太确定，因为我除了使用shim方案，我还测试了preloader方案，那个方案会一开始就启动一个MOK的工具进行证书导入，我记不太清shim到底需不需要手动导入了，如果出现了，那就导入一下就行了，没出现的话就能正常的看到引导界面和进入系统了。

还有一个后续的动作需要处理，就是内核升级以后，我们需要对内核重新签名，否则会被bios拒绝启动。

编辑/etc/pacman.d/hooks/99-secureboot.hook,并写入以下配置：

[Trigger]
Operation = Install
Operation = Upgrade
Type = Package
Target = linux
Target = linux-surface
Target = systemd

[Action]
Description = Signing Kernel for SecureBoot
When = PostTransaction
Exec = /usr/bin/sh -c "/usr/bin/find /boot/ -type f \( -name 'vmlinuz-*' -o -name 'systemd*' \) -exec /usr/bin/sh -c 'if ! /usr/bin/sbverify --list {} 2>/dev/null | /usr/bin/grep -q \"signature certificates\"; then /usr/bin/sbsign --key /etc/refind.d/keys/refind_local.key --cert /etc/refind.d/keys/refind_local.crt --output {} {}; fi' \;"
Depends = sbsigntools
Depends = findutils
Depends = grep

享受安全启动吧～

deepin git version

justforlxz — Sun, 06 Sep 2020 04:51:08 +0000

This repository only provides the git version of deepin. You can replace the deepin group in the community by installing the deepin-git group.

The PKGBUILD for all packages are there https://github.com/justforlxz/deepin-git-repo, Each branch saves the corresponding software.

Before adding this repository, you should first add the key used to sign the packages in it. You can do this by running the following commands:

wget -qO - https://packages.justforlxz.com/deepingit.asc \
 | sudo pacman-key --add -

It is recommended that you now fingerprint it by running

sudo pacman-key --finger DCAF15B4605D5BEB

and in a final step, you have to locally sign the key to trust it via

sudo pacman-key --lsign-key DCAF15B4605D5BEB

More infos on this process can be found at https://wiki.archlinux.org/index.php/Pacman/Package_signing#Adding_unofficial_keys. You can now add the repository by editing /etc/pacman.conf and adding

[deepingit]
Server = https://packages.justforlxz.com/

at the end of the file. See https://wiki.archlinux.org/index.php/Pacman#Repositories_and_mirrors for details.

to install deepin git version:

sudo pacman -Syy deepin-git

If you don’t want to use the repository anymore, you can uninstall deepin git, or install the deepin group in Community.

sudo pacman -Rscn deepin-git

to install deepin group for community.

sudo pacman -S deepin

使用VSCode远程开发DDE

justforlxz — Thu, 03 Sep 2020 03:14:38 +0000

本文将介绍如何使用VSCode的远程开发套件连接到Deepin主机，进行DDE和其他软件的开发与调试.

介绍

Visual Studio Code（简称VS Code）是一个由微软开发，同时支持Windows 、 Linux和macOS等操作系统的免费代码编辑器，它支持测试，并内置了Git 版本控制功能，同时也具有开发环境功能，例如代码补全（类似于 IntelliSense）、代码片段和代码重构等。该编辑器支持用户个性化配置，例如改变主题颜色、键盘快捷方式等各种属性和参数，同时还在编辑器中内置了扩展程序管理的功能。

在VSCode出来之前，Sublime曾经是前端开发者必备的软件，它使用python作为插件运行环境，并且也拥有不少的插件，但是很遗憾的是插件不能更改界面元素，可玩性不是很高。

再后来Atom作为GitHub的顶梁柱出现了，它基于使用Chromium和Node.js的跨平台应用框架Electron（最初名为Atom Shell），并使用CoffeeScript和Less撰写，并且支持js开发的插件，一时间拥有非常多的用户，并且从Sublime那里拉拢了非常多的前端开发者。

但是一切都在VSCode面世以后变了。VSCode同样也是基于Chromim和Electron开发，并且支持TypeScript开发插件，而且启动速度比Atom快很多，而且作为微软面向开源社区的主力产品，它和TypeScript一样，吸收了社区的很多意见和贡献，使得软件越来越好用。在语言支持方面，对 C#、JavaScript、和 TypeScript 等编程语言的原生支持最为完善。

安装VS Code

官网提供的有vscode的安装包，windows用户下载stable版本的exe(System Installer)。

System Installer可以自动下载对应语言的环境包，推荐安装此版本。

安装完成后就可以安装插件了。

安装插件

插件系统是一个编辑器的左膀右臂，emacs和vim作为终端下开发经常使用的编辑器，就拥有非常丰富的插件，几乎每个大佬使用的emacs和vim都不能互换使用。

dde的项目几乎都是cmake的项目，所以需要安装cmake插件和c++的插件，安装了这两个插件以后。vscode打开项目工程就会自动解析CMakeLists.txt，并且开启vscode的快速调试功能，还可以开始构建项目和调试项目了。

安装CMake、CMake Tools这两个插件就可以开发了。

安装C/C++和C++ Intellisense这两个插件可以对项目中的c++代码进行智能感知和代码补全，推荐安装。

安装Remote - SSH插件，可以让vscode通过ssh连接到目标机器，打开远程机器的目录和文件，并且在该模式下，部分插件可以自动切换成本地/远程模式，这样就可以在本机直接开发，但是操作的内容都是远程环境的。

安装完Remote - SSH插件以后，vscode的左下角就会有一个绿色的按钮，可以用来切换模式。

配置远程环境

因为是要在Windows上进行远程开发，如果是直接在UOS或者Deepin上开发DDE，这一部分是可以不用看的，上面的插件安装完成以后就可以开发项目了。

点击左下角的绿色按钮，在弹出的面板选择Remote-SSH: Connect to Host。

会继续弹出一个面板，用来选择配置ssh的连接。

选择Add New SSH Host添加一个服务器。

输入ssh的命令，例如 ssh lxz@10.20.32.54。

然后选择一个保存配置的位置，一般默认选择用户家目录的.ssh目录即可。然后就提示添加成功，此时可以点击Connect按钮进行连接。

输入密码

登录以后会打开一个新的窗口，并提示正在连接。连接成功以后可以在左下角看到机器的信息。

然后打开命令面板，选择在SSH中安装本地扩展。

在打开的列表选择全选，然后安装。

等待全部安装成功。

开发和调试

功能介绍

CMake插件提供了编译、运行和调试的功能和命令，可以点击下方面板中的select target，选择要运行的目标程序，选择切换编译模式，可以选择Debug或者Release。还可以选择使用哪个编译器进行构建。

设置启动参数

如果程序启动不需要提供参数，则可以直接点击下方面板的Debug按钮，或者打开命令面板选择CMake Debug Target，如果没有选择过Target，则会询问一次设置Target。

点击左侧的调试按钮，选择添加配置。

在弹出的面板选择GDB

此时vscode会创建出一个json文件，并生成了默认的配置文件。

我们需要进行一些调整，以便使用该配置文件进行调试。

program字段是程序二进制文件的位置，一般情况下我们是要手动写好路径，但是如果项目的二进制特别多，更换配置文件就会非常麻烦，而且配置文件里写死路径也不是很方便，我查阅了CMake插件的文档，发现CMake插件提供了两个很重要的变量，可以让我们方便的查找到路径。

"program": "${command:cmake.launchTargetPath}"

CMake插件提供了launchTargetPath的变量，它对应的是CMake插件选择的默认target，启动调试之前需要我们先选择好Target。

"value": "$PATH:${command:cmake.launchTargetDirectory}"

CMake插件还提供了launchTargetDirectory变量，用于获取程序启动所在的目录，一般需要我们指定到本次调试所需的环境变量中。

"environment": [
 {
 "name": "PATH",
 "value": "$PATH:${command:cmake.launchTargetDirectory}"
 },
]

然后我们就可以添加启动参数了。
args字段保存了程序启动会传递的参数列表，例如这里会给fuse传递-d和/tmp/x。

"args": [
 "-d",
 "/tmp/x"
]

完整的配置如下：

{
    "name": "(gdb) fuse",
    "type": "cppdbg",
    "request": "launch",
    "program": "${command:cmake.launchTargetPath}",
    "args": [
        "-d",
        "/tmp/x"
    ],
    "stopAtEntry": false,
    "cwd": "${workspaceFolder}",
    "environment": [
        {
            "name": "PATH",
            "value": "$PATH:${command:cmake.launchTargetDirectory}"
        },
    ],
    "externalConsole": false,
    "MIMode": "gdb",
    "setupCommands": [
        {
            "description": "为 gdb 启用整齐打印",
            "text": "-enable-pretty-printing",
            "ignoreFailures": true
        }
    ]
}

gdb调试

此时我们就可以先通过CMake插件构建整个项目，再切换到运行面板，启动调试。

点击下方面板的Build按钮，构建项目。

再点击左侧的gdb fuse(deepin-turbo)按钮，因为配置文件里面我们起的名字是gdb fuse。我们在main函数添加一个断点，用来测试gdb是否工作正常。

一切都工作正常，在调试控制台可以使用-exec作为前缀来执行gdb的命令。

调试图形程序

调试图形程序稍微有一些麻烦，因为是远程开发，图形程序又只能工作在目标机器，这里提供两个可行的方案。

synergy之类的键盘鼠标共享软件
在windows安装xserver

第一种方案是通过共享本机的键盘鼠标到远程机器，这样就可以在远程环境上面进行直接操作，好处是除了调试，也可以同时操作远程机器进行使用。

第二种方案是利用X11协议的网络透明，既图形程序和显示服务不一定在同一台机器上运行，我们只需要在Windows安装XServer程序，就可以让远程机器上的程序的画面显示到当前机器，并且可以操作。但是此方案有缺点，虽然设计上这种分离结构设计的很巧妙，但是因为远程OpenGL调用并不支持，所以图形无法调用3D程序渲染，并且和远程机器沟通需要大量的带宽，所以用起来体验并不好。

为了使用这两种方案，我们都需要在调试的launch.json中添加一个环境变量。

在运行面板点击齿轮按钮，可以编辑当前方案。

在打开的json文件中，找到environment字段，添加DISPLAY环境变量。

"environment": [
 {
 "name": "DISPLAY",
 "value": ":0"
 }
]

这样程序启动就有DISPLAY环境变量，我们就可以让程序在目标机器的屏幕上运行了。

还有一种自动化测试的方案，该方案是我个人认为所有开发都应该掌握的，通过自动化测试，我们就可以完全使用远程开发来完成开发任务，调试的时候只需要等待自动测试结果返回即可，设想一下，某个模块需要点击很多地方才可以重现一个问题，我们只需要设置好断点，让程序自动开始执行所有函数，并在最终出现问题的地方停下，我们就可以开始手动单步跟踪问题，完全不需要使用鼠标人工点击。（然而理想很美好，现实很残酷，我个人目前都没有掌握自动化测试的方式，现在也是只能通过鼠标点点点来重现问题。

在ArchLinux上开发startdde

justforlxz — Thu, 06 Aug 2020 08:14:26 +0000

dde 后端使用 go 作为主要的开发语言，使用 dbus 提供接口，主要使用 gsettings 来保存配置。所以在进行后端开发前需要对以上内容有基本的了解，这里假定本文档的阅读者熟悉 dbus 和 gsettings，并有一定的开发经验。

安装依赖

虽然本项目是go语言开发的，但是我们并没有直接使用go的mod作为依赖管理方案，而是走系统包管理器的方式，所以要先安装startdde的编译依赖。

sudo pacman -Sy golang-github-linuxdeepin-go-dbus-factory golang-deepin-gir golang-deepin-lib golang-deepin-dde-api go git jq golang-golang-x-net golang-github-linuxdeepin-go-x11-client

这些包会被安装到系统的/usr/share/gocode目录下。还需要手动go get一个依赖到本地的GOPATH中。

go get -v github.com/cryptix/wav

设置GOPATH

为了方便以后的开发，可以将GOPATH环境变量定义到~/.xprofile等文件中，或者shell的配置文件。例如我使用的zsh：

export GOPATH=$HOME/Develop/Go:/usr/share/gocode
export PATH=$HOME/Develop/Go/bin:$PATH

设置项目目录

go要求项目目录必须在GOPATH中，所以要将startdde放到GOPATH的pkg.deepin.io/dde/目录下，但是GOPATH每次进入不方便，可以采用软链的形式将startdde的目录链接到GOPATH下。

cd ~/Develop/Deepin
git clone https://github.com/linuxdeepin/startdde
mkdir -p ~/Develop/Go/src/pkg.deepin.io/dde/
ln -sf ~/Develop/Deepin/startdde ~/Develop/Go/src/pkg.deepin.io/dde/startdde

这样就可以在一个方便的目录进行开发了。

vscode开发工具

我个人推荐使用vscode当作开发工具，打开vscode安装go的插件，打开startdde目录，vscode会提示安装一些go的工具，选择全部安装即可。

use github action to check dde-launcher

justforlxz — Mon, 27 Jul 2020 10:14:21 +0000

本来打算7月份给dde添加github action验证，但是被各种事情耽误了，然后发现麒麟居然抢在我前面部署了全套的github action，这不能忍，赶紧把dde的github action也提上日程。并且打算听肥肥猫大佬的话，在aur给dde弄一套commit构建包，这样就可以在arch上使用比testing仓库更testing的dde了！

github actions是github官方出的持续集成功能，以前大家在github上的项目都使用的第三方的Travis CI或者自建jenkins构建，但是github被微软收购以后，微软为了表现出给社区和用户的诚意，将大量github的付费功能免费公开给开发者使用，希望能将github打造成开发者中心，于是在2019年微软推出了免费的github actions，每个项目都可以免费使用官方提供的持续集成和持续部署功能，这对第三方业务无疑是个巨大的打击，虽然Travis CI和jenkins等方式仍然有一定的市场，但是对于中小项目的开源项目，使用官方提供的功能无疑是方便的。

github actions的配置十分简单，只需要几个简单的步骤就可以实现构建、执行和测试代码。并且可以使用Linux、Windows和MacOS环境，机器性能也十分强劲，编译速度非常的快。

这是给dde-launcher的一份基础配置，需要将配置文件放在.github/workflows/目录下，以build.yaml文件名保存。

name: CI Build

on:
 push:
 branches:
 - UOS

 pull_request:
 branches:
 - UOS

jobs:
 archlinux:
 name: Archlinux Build Check
 runs-on: ubuntu-latest
 container: docker.io/library/archlinux:latest
 steps:
 - name: Checkout branch
 uses: actions/checkout@v2
 - name: Refresh pacman repository
 run: pacman -Syy
 - name: Install build dependencies
 run: pacman -S --noconfirm base-devel cmake ninja qt5-tools deepin-qt-dbus-factory dtkwidget
 - name: CMake & Make
 run: |
 mkdir build
 cd build
 cmake ../ -G Ninja
 ninja

介绍一下配置文件吧，name是设置ci的名字，github允许有多个ci存在，可以做不同的事情，例如部署三个ci，一个做语法检查，一个做静态检查，一个做编译检查。name就是用来在界面上显示的。on是设置ci对哪些事件感兴趣，在这里我设置了push和pull_request，当发生push和pull request时，这个ci就会被启动，执行接下来的jobs的内容。jobs里是可以设置多个任务的，同样name字段也是用来展示本次动作的名称。runs-on是设置该job工作的环境，ubuntu-latest是linux环境，container是指使用哪个docker容器，github actions是可以使用docker的，也可以将自己的ci配置共享给其他人使用。run就是执行命令了，在配置文件中我手动运行了刷新仓库和编译项目所需的命令。job的steps可以理解成shell中一次动作的执行，uses是使用其他人封装好的命令，run则是执行本地命令。

可以看出github actions的配置是十分简单的，并且构建速度也非常的快，并且构建环境是使用的arch linux环境，为什么要选择arch作为ci的基础构建环境呢，原因当然不是因为和肥肥猫有py交易，arch上的dde更新速度很快，并且很多用户都使用arch+dde的方式使用linux，deepin自己维护的发行版因为基础仓库更新较慢，不适合一些用户，所以为了能让dde被更多的人接受和使用，在arch上及时更新dde是十分有必要的。所以才选择actions的环境为arch linux。

使用perf工具分析程序性能

justforlxz — Tue, 21 Jul 2020 01:15:11 +0000

最近在对DDE进行性能优化，所以补习了一下linux下的各种分析工具的使用方法。

这张图是来自Brendan Gregg大佬提供的linux分析工具的应用场景，可以看出几乎包含了系统每个地方应该用什么工具去分析。

Linux Perf Tool

允许系统进行分析

为了能够正常分析，首先需要打开系统的调试功能，允许我们去对其他进程进行访问。

SysCtl

较新的Linux内核具有sysfs可调参数/proc/sys/kernel/perf_event_paranoid，该参数允许用户调整perf_events非root用户的可用功能，数量越大则越安全（相应地提供较少的功能）：

Consider tweaking /proc/sys/kernel/perf_event_paranoid:
 -1 - Not paranoid at all
 0 - Disallow raw tracepoint access for unpriv
 1 - Disallow cpu events for unpriv
 2 - Disallow kernel profiling for unpriv

默认值是不允许获取任何信息，所以我们需要修改为1或者0，允许我们访问CPU的事件信息。

临时修改

执行命令向内核接口直接写入值。

sudo tee /proc/sys/kernel/perf_event_paranoid <<< 1

永久修改

使用sysctl来配置其值，创建/etc/sysctl.d/50_perf_event_paranoid.conf文件，并写入kernel.perf_event_paranoid=1，执行sysctl -p来刷新系统配置。

perf 采样

性能优化相关的三种类型的工具，一种是sampling类型的，即采样，这种工具就是不停“询问”程序在做什么，perf在我们使用的这种模式下就是 sampling模式，如果是追踪某些event，就工作在trace模式，实际上就是第二种类型的工具，这种工具主要依靠事件或者hook，程序在运行的过程中不停主动告诉工具它自己在做什么，比如 strace；第三种是 instrument 类型的，这种主要就是依赖编译器进行插桩，精确知道代码行级别的执行情况（参考gcc instrumentation ）。
by hualet on deepin 15.7

我们通过perf record命令才对程序进行采样记录。

perf record -g --call-graph=dwarf -F 99 /usr/bin/dde-shutdown

命令介绍：

-g: 即采样全部信息
--call-graph: 设置并启用调用图（堆栈链/回溯）记录，参数有fp(frame pointers)、dwarf(debug information)和lbr(Last Branch Record)。
-F: 采样率

perf可以直接启动一个程序进行分析，也可以使用-p参数指定一个pid进行采样。

查看 perf 的采样结果

当我们通过perf record完成采样以后，会在执行目录生成perf.data文件，此时我们就可以使用perf report命令对data文件进行数据分析了。

perf report --stdio

perf report会自动打开当前目录下的perf.data文件，当然也可以在最后指定perf.data文件的路径。

perf report会根据–call-graph参数来生成不同的图，使用dwarf参数时会以函数调用栈的顺序来显示，使用这种方式可以方便的看出哪个函数执行的时间比较长，因为每次采样都能落到该函数上，也就意味着函数执行的时间非常长，再通过调用栈的深度来分析函数执行期间都在做什么事情。

hotspot火焰图

在命令行下查看函数调用不是特别方便，所以就有图形化的工具用来方便的查看perf工具的生成结果，其中使用比较友好的是kde开发的hotspot工具，该工具可以直接打开perf.data文件，并生成对应的火焰图，火焰图是函数调用的另一种表现形式，火焰越高，也就意味着调用栈越深，火焰越广，也就意味着函数执行的时间很长。

2019 Review

justforlxz — Wed, 01 Jan 2020 13:25:54 +0000

上一次写年终总结还是18年回家的动车上，可惜写了一半没发表，觉得一年了没有什么能够回想起来的，就又删除了。今年不同了，今年有好多想说的。

脱单

第一件重要的事是我遇到了生命中的她。

自从工作以后，我妈天天念叨我的就是找对象，和我预想的没错，上学的时候盼我毕业，毕业以后盼我工作，工作以后盼我找对象结婚，找对象以后盼我赶紧生个娃让她抱。~~（大家的父母应该都这样）~~

加薪

这件事确实也令我挺开心的，我的工资在2019年成功涨到了0.375乔(1乔等于**元 @nanpuyue)

涨工资谁不高兴，我估计也就马云不高兴了，毕竟他看不上钱。

学习

今年看了很多C++的资料，对C++和编译器都有了更深的了解。想2016年半夜@zccrs在家教我编译原理，到现在我可以理解一门语言从设计到实现，再到使用模板完成编译时计算，我走了快三年，这三年里我一直没停下学习的脚步，在学习各种知识，从各种编程语言到各种框架原理，到图形界面的实现。还学习了单元测试，并且@hualet大佬给我讲了单元测试是什么，以及单元测试的重要性，从那以后我才算真正的了解单元测试的重要性，也使我在写代码的时候注重通过单元测试来保障我的功能。

去年对深度学习进行了一波学习，今年对Web工程化和TypeScript也学习了一下，也算是对目前最热门的两个领域进行了一定的了解。

读书

去年买的TensorFlow看了没一半，今年倒是没买书，开始在微信读书上读书，利用一些空余时间读一点，我也推荐大家多利用空闲时间读读书，少刷抖音和bilibili。

《TensorFlow》未读完
《TypeScript实战》正在读

博客

2019年我一共水了15篇文章。

12-26 在ArchLinux通过串口调试VMware虚拟机中的deepin
12-26 使用标准库std::sort函数进行排序
12-09 记录一个坑爹的usb网卡
12-09 使用github actions自动部署hexo文章到html仓库
12-08 Vue父子组件传值 —— props & $emit
12-08 添加Vue动画
11-25 使用webpack-dev-server来监听项目变化
10-24 给Archlinux开启BFQ和MuQSS
10-22 使用webpack打包Vue和TypeScript
10-14 webpack入门
06-16 wsl2的使用体验
06-15 入坑typescript了
05-23 CMake CTests for dde-control-center
02-21 如何在Deepin上使用LNMP
02-23 解决用了xposed后淘宝闪退

2019
├── 01
│   └── 23
│   └── fuck-taobao
│   └── index.html
├── 02
│   └── 21
│   └── how-to-use-LNMP-on-deepin
│   └── index.html
├── 05
│   └── 23
│   └── CMake-CTests-for-dde-control-center
│   └── index.html
├── 06
│   ├── 15
│   │   └── 入坑typescript了
│   │   ├── 深度录屏_选择区域_20190615202044.gif
│   │   └── index.html
│   └── 16
│   └── wsl2的使用体验
│   ├── index.html
│   ├── Snipaste_2019-06-16_21-49-15.png
│   └── Snipaste_2019-06-16_21-52-42.png
├── 10
│   ├── 14
│   │   └── webpack入门
│   │   └── index.html
│   ├── 22
│   │   └── 使用webpack打包Vue和TypeScript
│   │   └── index.html
│   └── 24
│   └── 给Archlinux开启BFQ和MuQSS
│   └── index.html
├── 11
│   └── 25
│   └── 使用webpack-dev-server来监听项目变化
│   └── index.html
└── 12
 ├── 08
 │   ├── vue-component-props
 │   │   └── index.html
 │   └── vue-transitions
 │   └── index.html
 ├── 09
 │   ├── 记录一个坑爹的usb网卡
 │   │   └── index.html
 │   └── use-github-actions-to-depoly-hexo
 │   └── index.html
 └── 26
 ├── cpp-sort
 │   └── index.html
 └── use-serial-port-debug-deepin-on-archlinux
 └── index.html

34 directories, 18 files

科普视频

妈咪叔 (一个较真的理工男)

这个名字我第一眼看到的时候，还以为是个卖母婴的，没想到居然是个搞科普的，而且内容讲的也很好，有数学、物理、化学和天文学。

李永乐老师

以前偶尔看过老师的视频，因为一直都在热榜，所以没想到关注，后来是youtube上看到了，就点了关注，youtube上更新的和bilibili的还不是一样的，看最后结尾的时候youtube的只说youtube帐号关注，而bilibili的是bilibili，有时候还要多个平台去看。

萝王二号

之前在科普区随便看的时候，对生物学产生了一些兴趣，萝王讲的风格我很喜欢，特别是他注重昆虫分类学(骨包皮，皮包骨啊2333)，还有一些辟谣视频。

芳斯塔夫 (鬼古)

也使对生物学产生了一些兴趣，鬼古说以他很中二的风格带领我学习了一波古生物的相关知识(旧日支配者！！！)。

木偶君

和鬼古一样是专门讲古生物的，不过每次结束的比较仓促，突然就结束了。

木鱼水心

木鱼并不是今年才关注的，最开始关注是他做EVA剧场版解析，后来《木鱼说》开始做一些科普，我开始一直关注了。

宇宙视觉 (永远不要停止思考)

一个讲天文的科普up，不过年底的时候换了配音，疑似配音出去单干了。

电影

流浪地球
阿丽塔：战斗天使
战狼2
惊奇队长
复仇者联盟4
何以为家
速度与激情：特别行动
叶问4

纪录片

混沌：数学探秘
维度：数学漫步

动漫

刀剑神域
紫罗兰永恒花园
darling in the franxx
心理测量者
进击的巨人第三季
五等分的新娘
citrus～柑橘味香气～

在ArchLinux通过串口调试VMware虚拟机中的deepin

justforlxz — Thu, 26 Dec 2019 09:26:13 +0000

电脑主板上的接口：进行串行传输的接口，它一次只能传输1Bit。串行端口可以用于连接外置调制解调器、绘图仪或串行打印机。它也可以控制台连接的方式连接网络设备，例如路由器和交换机，主要用来配置它们。消费性电子已经由USB取代串列接口；但在非消费性用途，如网络设备等，串列接口仍是主要的传输控制方式。

首先给虚拟机分配一个串口设备，选择Settings->Add->Serial Port。分配好串口设备以后，我们需要选择一个串口设备的调试方式，一个是将输出转向一个文件，或者是通过socket。

如果只是查看方式，选择outpu file即可。如果需要调试，则可以通过socket方式来进行。

socket方式需要给一个固定的路径分配/tmp/，我调试的时候给出的是/tmp/vhost，From选择Server，To选择An Application。From的意思是信息从哪里来，信息是虚拟机里的系统发出的，所以这里选择的是Server，如果是反向操作，需要选择Client。To也是有两个选项，第一个是An Virtual Machine，第二个是An Application。用于把消息发送给另外的虚拟机，或者是宿主机的一个应用程序。

安装minicom包，用于进行调试，minicom这个东西，不是太好用，退出方式是先按Ctrl+A，然后按q，有时候还不一定管用，不知道是没接受到，还是按错了。

先minicom -s 进行初始化，选择Serial port setup，按A编辑Serial Device，这里需要注意一下，通过socket进行调试，需要使用unix#前缀，然后加上在虚拟机里写的路径 unix#/tmp/vhost。然后保存，选择Exit，退出以后其实重启minicom，就进入minicom的调试界面了，然后此时开启虚拟机，给内核添加一个console=ttyS0的参数，就看到minicom显示输出的信息了，还可以交互。

[ 3.855725] [drm:vmw_fb_setcolreg [vmwgfx]] *ERROR* Bad regno 254.
[ 3.857125] [drm:vmw_fb_setcolreg [vmwgfx]] *ERROR* Bad regno 255.
deepin Login:

CTRL-A Z for help | unix-socket | NOR | Minicom 2.7.1 | VT102 | Offline | unix#/tmp/vhost

此时就可以交互了，用法和tty一样，最后一行是minicom的输出，可以看到CTRL-A Z可以看help，minicom的版本，和访问的串口socket。

开发DDE的屏保

deepin 社区官方博客 — Tue, 03 Sep 2019 12:41:00 +0000

还记得刚推出屏幕保护功能那会儿，我偶逛论坛，围观大家对这个功能的评价。其中让我印象最深的一句话就是：“一股Windows98风”，总之，评价总结出来就是一个字：“吃藕”。

大家追求美好事物的诚挚之心深深地打动了我，而且，我个人做事情的风格是喜欢未雨绸缪，在屏幕保护程序开发之初，就已经定好了易于扩展的架构，所以我当时就下定了决心，为大家开发一个非Windows98风格的屏保。

为了达到绝对“非Windows98”的目的，我特意选择了Windows10中的默认屏保作为参考，在无数个周末的战斗下，最终成功将名为“泡泡”的屏保应用发布到了商店（项目地址：https://github.com/zccrs/screensaver-pp ）。

本着“授人以鱼不如授人以渔”的理念，特地整理了这篇文章协助大家开发一款属于自己的时尚屏保应用。

正文

在Linux+X11生态环境中，xscreensaver是最“流行”的屏幕保护程序，有着非常多的屏保资源，所以deepin-screensaver必然要兼容它的资源。

但是，xscreensaver对屏保资源的扩展方式并不符合deepin的开发理念，因此，deepin-screensaver实现了一套全新的屏保扩展方式。

支持使用Qt qml模块编写屏保应用，一个标准的屏保应用只需要包含一个 “xx.rcc” 文件，将文件安装到 /usr/lib/deepin-screensaver/resources目录。

rcc 格式是一个编译之后的Qt资源文件，在这个资源文件中至少要包含两个文件：qml代码文件、屏保封面图。

图中文件名括号内为其别名，也就是屏保主应用加载文件时能读取到的文件名。

qml代码文件：屏保应用的代码入口，会被屏保主程序加载显示
屏保封面图：设置屏保入口显示的预览图，支持svg png jpeg bmp等格式所有的文件必须以特定的目录结构组织到一个Qt资源文件（qrc文件），以“泡泡”屏保为例：qml.qrc 为其资源文件，包含三个前缀路径
/deepin-screensaver/modules：放置屏保应用的主qml文件，此路径下的所有qml文件都会被当做一个独立的屏保应用，因此，项目中的其它文件需要额外建立新的前缀放置
/deepin-screensaver/modules/cover：放置屏保应用封面图文件，文件名称必须和modules目录中的qml文件一致，且包含它的 “.qml” 后缀。如图上，qml文件全名为：“pp.qml”，封面图全名为：“pp.qml.svg”。
/deepin-screensaver/modules/pp：此前缀不是必须的，用于放置项目中的其它文件。为了不与其它项目产生冲突，建议使用项目名作为目录名称资源文件最好以项目名称命名，避免和其它屏保应用冲突。另外，大家可能已经发现了，这三个前缀都有一个共同点，那就是以 “/deepin-screensaver/modules"开头，的确，这是一个格式要求，不能随意更改路径。

主qml文件作为屏保应用的入口，它的根元素一定要设置

anchors.fill: parent

这样才能确保屏保应用充满整个屏幕。在多屏的情况下下，会创建多个窗口示例，可根据屏幕绘制不同的屏保内容。项目编译其实很简单，只需要使用Qt提供的rcc命令将qrc文件编译为rcc文件即可，使用qmake构建系统时，可以在pro文件中调用以下命令：

system(rcc --binary $$_PRO_FILE_PWD_/xx.qrc -o $$_PRO_FILE_PWD_/xx.rcc)

当然，最后不要忘记将 xx.rcc 文件安装到deepin-screensaver所要求的目录。做完这所有的步骤后，回到桌面，在右键菜单中选择“壁纸与屏保”，切换到屏保设置后即可看到新添加的屏保应用。另外，deepin-screensaver为qml提供了获取当前屏幕截图的接口，只需要为Image项指定特定的路径即可：

Image {
anchors.fill: parent
source: "image://deepin-screensaver/screen/" + Screen.name
}

由于要获取屏幕名称，上述代码需要 “import QtQuick.Window 2.2” 使用

后记

屏保封面图最佳比例为：8:5，推荐使用svg格式，以更好的适应高分屏缩放。

推荐大家使用Qt Creator作为项目的开发工具，可以方便的编辑 qrc 文件。

泡泡屏保是一个完整的demo，有任何疑问的地方都可以以其作为参考

参考

“泡泡”屏保项目：https://github.com/zccrs/screensaver-pp
Qt资源文件：https://doc.qt.io/qt-5/resources.html

如何在Deepin上使用LNMP

justforlxz — Thu, 21 Feb 2019 02:11:15 +0000

为了节省读者的时间，我先简述一下阅读这篇文章需要了解的知识。

这篇文章将基于Docker来构建nginx、php和mysql来搭建LNMP环境，和其他教程有所不同的是，需要有一定的Docker基础。

Docker是一个不错的工具，使我们不需要虚拟机那样的庞然大物就可以轻松的隔离运行的程序，这要感谢Linux的资源分离机制，避免启动一个虚拟机造成了大量资源浪费。

首先需要在Deepin上安装Docker，添加Docker的deb仓库，并安装docker-ce。

创建文件

sudo nano /etc/apt/sources.list.d/docker.list

写入

deb [arch=amd64] https://download.docker.com/linux/debian jessie edge

刷新一下仓库就可以安装了。

sudo apt update && sudo apt install docker-ce docker-compose

安装完成后重启一下系统，准备工作就算完成了一半了。

在家目录创建一个Projects目录，当做我们LNMP的工作目录，创建一个名叫docker-compose.yaml的文件，这是docker-compose的配置文件，我们通过docker-compose这个工具来管理我们的Docker容器。

所有的镜像均采用最新版本，nginx(1.15.8)，php(7.3.2)，mysql(8.0.15)，如有需要，自行选择不同版本的镜像。

注意PHP7已经不支持mysql扩展，使用内置的MySQLnd。

写入以下配置文件：

version: '3'

services:
 nginx:
 # 设置容器名字
 container_name: "nginx"
 # 采用最新的nginx
 image: nginx:latest
 # 绑定80端口
 ports:
 - "80:80"
 # 添加php容器的依赖
 depends_on:
 - "php"
 # 绑定数据目录
 volumes:
 - "./volumes/nginx/conf.d:/etc/nginx/conf.d"
 - "./volumes/html:/usr/share/nginx/html"
 restart: always

 php:
 # 设置容器名字
 container_name: "php"
 # 采用最新的php
 image: php:fpm
 # 绑定端口
 ports:
 - "9000:9000"
 # 绑定数据目录
 volumes:
 - "./volumes/html:/var/www/html"
 restart: always

 mysql:
 # 设置容器名字
 container_name: "mysql"
 # 采用最新的mysql
 image: mysql:latest
 # 绑定端口
 ports:
 - "3306:3306"
 # 设置环境变量
 environment:
 - MYSQL_ROOT_PASSWORD=(自己设置密码)
 # 绑定数据目录
 volumes:
 - "./volumes/mysql:/var/lib/mysql"
 restart: always

创建nginx的配置文件，编辑 ./volumes/nginx/conf.d/nginx.conf ：

server {
 listen 80;
 server_name localhost;
 location / {
 root /usr/share/nginx/html;
 index index.html index.htm index.php;
 }
 error_page 500 502 503 504 /50x.html;
 location = /50x.html {
 root /usr/share/nginx/html;
 }
 location ~ \.php$ {
 fastcgi_pass php:9000;
 fastcgi_index index.php;
 fastcgi_param SCRIPT_FILENAME /var/www/html/$fastcgi_script_name;
 include fastcgi_params;
 }
}

创建php测试文件，编辑 ./volumes/html/index.php :

<?php
phpinfo();
?>

启动docker，第一次需要拉取一下镜像:

docker-compose up --build -d

等全部结束以后，就可以访问localhost看到php的信息了。

通过Docker的方法来使用LNMP，不污染宿主机环境，不会再因为各种依赖问题而搞坏系统，这恰恰是新手容易犯的错误，使用Docker，方便你我。

修理 FreeRDP

deepin 社区官方博客 — Mon, 17 Dec 2018 06:00:00 +0000

头段时间入了一个大坑儿，大概被坑了有一个月之久，出来之后同事还不忘嘲讽一番：”这么个事情就搞了一个月，看吧，你果然是老了“。听了这句话，心里真是百般滋味，但转念一想，”我年轻的时候做事好像也不怎么快“，顿时也就释怀了 🙂

这个坑就是”给 FreeRDP 的 RAIL 模式添加托盘支持“，当然，跟所有的需求一样，这么具有总结性而又直指根源的需求描述，绝对不是它最原始的模样——我刚接到这个坑的时候，它是这样的：FreeRDP 的 RAIL 模式下，应用的托盘在我们 DDE 下不显示。请注意这里说得是不显示，而不是后来发现的压根儿没有支持！

FreeRDP

说到这，可能有读者还不了解 FreeRDP 和 RAIL，所以先简单介绍一下。

RDP 其实是一个协议名称，全称 Remote Desktop Protocol（远程桌面协议），是微软公司开发的一套用于远程桌面展示和操作的协议，FreeRDP 就是它在开源世界的实现咯。而 RAIL 的全称是 Remote Application Integrated Locally （远程应用本地集成），其实就是非常类似大家熟悉的虚拟机的”无缝模式“，通过将应用的显示跟本地环境相融合，让用户完全感受不到这个应用其实不在本机运行——就是这么一种技术。

问题也就出在这，我当时第一反应是这么老的技术实现肯定比较完整了，托盘没有显示出来应该是跟 DDE 的兼容性有点小问题，稍微修一下就完了，三下五除二的事情，所以满口答应了下来……

经过

既然答应了，硬着头皮也要顶下去的。何况调 BUG 这种事情——不管是不是我们自己的问题——在深度都是家常便饭。慢慢地，调各种项目的 BUG 竟然成了我的一种乐趣——每次开始接手一个新的项目的时候，我都把自己当成了福尔摩斯或者胡八一，或者也可以是其他全世界最聪明的那类人 ?，在通过代码找寻问题线索的过程中，慢慢成为这个项目世界中的主宰，解开真相……

额……不好意思，白日梦又发作了一会儿。总之，这次也不例外，而且刚好这次在调问题的过程中有记录几个关键环节，所以打算把中间的过程写成日记性质的记录，看看能不能有更好的阅读效果：

2018-11-14

从”沈老板“那收到需求，说 FreeRDP 在我们系统上有问题，应用的托盘显示不出来，QQ之类的程序关闭了窗口以后就没办法显示出来了，无法使用。这丫的又拿刘老大来压我……呵呵，想削他。不过看在他快要当爸爸的份上，还是算了。问了下时间要求，大概需要两周左右有初步的结果。不过我自己最近没有什么时间，先把锅丢给了印象中还比较熟悉网络协议的 @Blumia 同学。

2018-11-15

从 @Blumia 那收到反馈，可能 FreeRDP 没有实现托盘图标这部分的功能，我怕他一个人搞不定，简单翻了翻 FreeRDP 的项目 wiki 和 RDP 的一些介绍，给了他，让他先帮忙找一下需要补充实现部分的代码结构。

2018-11-16

没时间处理。

@Blumia 搭了测试环境。

中间几天两个人都没有时间处理 FreeRDP的事情。

2018-11-22

留了少部分时间，看了 FreeRDP 的代码，大概找到了托盘图标相关处理应该在的位置。

RAIL 主要接口的实现都在 xf_rail.c 中。
托盘图标相关的处理在 xf_rail_no``t``ify_icon_* 相关的函数，这些函数在 xf_rail_re``gi``s``t``er_``u``pdate_call``b``a``c``ks 里面被注册到 rdpWind``o``wUpdate 对象上。
部署了一份测试服务器的虚拟机。
在 wf_rail.``c 中发现一个 PrintRailI``c``onInfo 函数，放在 xf_``r``ail_notify_i``c``on_common 中打印了获取到的图标的信息，发现能正常获取一些图标的数据。
xf 应该是 x11 freerdp 的缩写，而 wf 应该是 windows freerdp 的缩写。 中间又是几天没有时间处理 FreeRDP 的事情。

2018-11-27

有半天的时间看 FreeRDP 的代码，同时跟 FreeRDP 的邮件列表发了邮件询问相关技术问题，主要是为了验证自己的想法，没有指望有回复或者什么比较大用处的信息，只是希望如果自己想法是错的，有人及时纠正一下。

图标显示的问题不打算优先处理，现在的问题变成如何让服务端知道了本地用户点了托盘图标。
搜了一下 event 相关的文件，发现 x``f_event.c ，怀疑 X 相关的事件都是在这里面处理的，这个也不用急着去证明，先看看 client 怎么让 server 感知本地的事件。
没有头绪，只好看了一下 RAIL 的主要协议，发现 Cli``e``nt Notify Ev``en``t。
怀疑托盘图标在 client 端（本地端）的事件是通过 ClientNotifyEvent 发送给 server 端的。
ClientNotifyEvent 相关：
- rail_main.``c 中的 Vi``r``tualChann``e``lE``n``tryEx 应该是 RDP 中 RAIL 相关的 channel 处理的函数。

2018-11-28

上午继续看了 FreeRDP 的代码。

V``i``rtualCha``n``nelEntryEx 中给 RailClientContext 设置的哪些成员函数，有些函数（Server开头的）都是需要真正的 client 去实现的，Client 开头的函数（包括 ClientNotifyEvent）都是默认有实现，但是这些 Client 开头的函数都是在哪调用的呢？找到重要线索：

/**
* The position of the X window can become out of sync with the RDP window
* if the X window is moved locally by the window manager. In this event
* send an update to the RDP server informing it of the new window position
* and size.
*/
void xf_rail_adjust_position(xfContext* xfc, xfAppWindow* appWindow)
{
RAIL_WINDOW_MOVE_ORDER windowMove;
if (!appWindow->is_mapped || appWindow->local_move.state != LMS_NOT_ACTIVE)
return;
/* If current window position disagrees with RDP window position, send update to RDP server */
if (appWindow->x != appWindow->windowOffsetX ||
appWindow->y != appWindow->windowOffsetY ||
appWindow->width != appWindow->windowWidth ||
appWindow->height != appWindow->windowHeight)
{
windowMove.windowId = appWindow->windowId;
/*
* Calculate new size/position for the rail window(new values for windowOffsetX/windowOffsetY/windowWidth/windowHeight) on the server
*/
windowMove.left = appWindow->x;
windowMove.top = appWindow->y;
windowMove.right = windowMove.left + appWindow->width;
windowMove.bottom = windowMove.top + appWindow->height;
xfc->rail->ClientWindowMove(xfc->rail, &windowMove);
}
}

其中有主动调用 RailClientContext 的 ClientWindowMove 函数。这个函数又是 xf_``e``v``en``t.``c 中 xf_``e``v``en``t_C``o``nfig``u``r``e``Notify 有调用，再加上这个函数的注释说明，差不多能证明所有的 X事件相关的都是在 xf_event.c 中处理的，跟之前的猜测一致。
那样的话如果想发送事件到 server，应该就是在 xf_event.c 中收到我们自己创建的托盘图标的点击事件后，发送一个 ClientNofityEvent 。尝试在收到 xf_r``a``il_``no``ti``f``y_``i``con_u``p``d``a``te 的时候主动调用一次 Cli``ent``NotifyEvent 看看会发生什么。

RAIL_NOTIFY_EVENT_ORDER notifyEvent;
notifyEvent.windowId = orderInfo->windowId;
notifyEvent.notifyIconId = orderInfo->notifyIconId;
notifyEvent.message = NIN_SELECT;
xfContext* xfc = (xfContext*) context;
xfc->rail->ClientNotifyEvent(xfc->rail, &notifyEvent);

选择 message 为 NIN_SELECT 是因为根据 r``ail.h 里面仅有的零星注释，只能推测这个可能是针对托盘的。
试了下，没有任何反应。尝试换成 NIN_KEYSELECT ，更不行。
硬着头皮又翻了一下协议，发现 Notificat``i``o``n``I``c``on Info``r``mation 这段，随便翻了一下，看起来没有有用信息。
偶发奇想搜了一下 select 关键字想看一下这个到底是什么意思，偶然发现 Cli``en``t Notify E``ve``nt PDU 这一节（能跟源码 r``ai``l``.h 里面的一些注释对应上），里面有 WM_LBUTTONDOWN 、 WM_LBUTTONUP 等针对托盘图标的动作定义。
真是对自己做事情毛毛躁躁的行为无语了，要不是心血来潮，差点就错过这么重要的信息。
把 message 改成 WM_LBUTTONDOWN 和 WM_LBUTTONUP ，满怀期待。
测试还是无效果……仍旧不死心，怀疑测试程序（@Blumia 同学搞的一个音乐程序）的稳健程度。
使用 TIM 再试，还是不行，不能唤出主窗口。
感觉走进了死胡同。

2018-11-29

继续看 FreeRDP 的问题，主窗口隐藏后不能显示的问题太奇怪了，得找一个简单点的程序，排除复杂影响。

让 @zccrs 写了一个简单的窗口程序，定时隐藏、显示窗口。
发现程序窗口隐藏后无法再显示出来……
赶紧给上游报了一个 issu e ，希望上游能修复。但是也不能期望上游很快能修复这个问题，所以自己还是尝试看代码……
上游回复还挺快的，但是对方好像是 FreeRDP 目前的维护者，说自己对 RAIL 这部分协议本身还不是特别熟悉。
不能依赖的上游不是好上游，继续看代码，发现在窗口的显示隐藏主要是通过 WINDOW_STATE_ORDER 中的 s``h``o``wState 控制的，处理的函数是 xf_``r``ail_window_``c``o``m``mon ，里面调用了 xf_ShowWin``d``ow 这个函数，但是这个函数在该显示窗口的时候只是调整了一下窗口的最大化、最小化状态，并没有 Map 这个本地窗口。
加了 XMapW``in``dow(xf``c``->di``s``pl``a``y, appWi``n``dow->ha``n``dl``e``) 这行，满心期待 bugfix。
编译代码测试，发现窗口连关闭都不能关闭了……
xfContext 的 appWindow 是本地窗口的一个抽象表示。

2018-12-03

觉得这个事情没有什么太大的希望了，不过既然已经知道托盘图标的显示方式和事件的发送，但是没有实际实现，到时候”沈老板“来问，也不好说都是在脑子里，干脆先把之前测通但是没有实现的内容实现一下。

托盘窗口加好了，事件也都加上了。
眼看着都快要完美了，就差那么一点问题没有解决，实在是不甘心，继续死磕那个问题。
尝试了各种手段调试，跟整个程序的命令传递，都没有能解决问题。

2018-12-04

调试了一天，一遍又一遍看窗口事件，一点一点排除事件处理函数，终于发现了上游犯的一个低级错误，我很怀疑当时作者有没有测试一下 🙁

做了修复，提交了 PR，并且顺利合并。

心情终于舒畅了。

中间有事请假一天

2018-12-06

托盘图标也画上了，不过怎么感觉颜色有点偏。

调了一下颜色的格式（RGBA -> BGRA），图标显示正常了。

事情终于告一段路了。

结束

折腾了这么长时间，事情终于搞定了，这应该是最近一年里面时间拉的最长的 BUG 了。

实现算是完了，也能使用。但是还有一些细节没有特别完善，已提交提交到上游一个新的 PR ，希望能早日合并造福一方用户。

感想

感觉我之前对 wine 有偏见，一直比较拒绝使用（或者大量使用）wine 的东西，但是实际上在修复 FreeRDP 的过程中，我竟然觉得这也是一种不错的解决方案……仔细想想，还是 wine 方便一点，至少不需要依赖一个服务端。

准备入坑 wine 啦 ~(≧▽≦)/~

使用swapfile来休眠

justforlxz — Wed, 12 Dec 2018 03:01:55 +0000

最近deepin要添加休眠功能，但是之前测试的通过swapfile来休眠失败了，所以对正在使用swap分区的用户提供休眠功能。但是昨天我在askubuntu上看到有人发了在ubuntu下通过swapfile休眠的方案，今天试了一下，效果良好，觉得可以考虑给deepin也加上这样的功能。

原文链接: Hibernate and resume from a swap file

具体步骤是通过uswsusp这个包来做的，uswsusp是一组用户空间工具，用于Linux系统上的休眠(挂起到磁盘)和挂起(挂起到RAM或待机)。详细内容可以在ArchWiki上参考。点这里

先创建一个和内存同等大小的swapfile，为了确保休眠成功，不能小于内存的容量。

sudo fallocate -l 16g /swapfile # 我的机子是16G，具体自己修改
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile swap swap defaults 0 0' | sudo tee -a /etc/fstab

安装用户空间软休眠(Userspace Software Suspend)包

sudo apt install uswsusp

创建需要的配置文件，只需要创建文件即可。

sudo touch /etc/uswsusp.conf
sudo dpkg-reconfigure -pmedium uswsusp

这时候终端会提醒是否继续，选择Yes，然后会要求你创建一个密码，设置一个密码继续即可。

此时就可以测试一下功能了，不过我是跳过这个步骤了(比较喜欢作死)。

修改systemd的hibernate服务，使用uswsusp来代替systemd的功能。

sudo systemctl edit systemd-hibernate.service

写入以下内容:

[Service]
ExecStart=
ExecStart=/usr/sbin/s2disk
ExecStartPost=/bin/run-parts -a post /lib/systemd/system-sleep

这时候可以使用systemd的命令来测试的，我表示工作的非常正常。

systemctl hibernate

执行以后可以看到屏幕上会打印当前保存的进度，然后设备就关机了，此时再开机，等待一会儿以后就看到了背景是我漂亮老婆的锁屏，解锁以后看到工作区还是执行命令前的，一切ok。

参考以下内容:

https://askubuntu.com/questions/6769/hibernate-and-resume-from-a-swap-file

https://wiki.archlinux.org/index.php/Uswsusp

在DeepinLinux下使用nVidia CUDA

justforlxz — Wed, 27 Jun 2018 19:21:50 +0000

CUDA（Compute Unified Device Architecture，统一计算架构）是由NVIDIA所推出的一种集成技术，是该公司对于GPGPU的正式名称。通过这个技术，用户可利用NVIDIA的GeForce 8以后的GPU和较新的Quadro GPU进行计算。亦是首次可以利用GPU作为C-编译器的开发环境。NVIDIA营销的时候，往往将编译器与架构混合推广，造成混乱。实际上，CUDA可以兼容OpenCL或者自家的C-编译器。无论是CUDA C-语言或是OpenCL，指令最终都会被驱动程序转换成PTX代码，交由显示核心计算。

在论坛上看到有些用户希望在deepin下使用CUDA，但是他们采取的做法往往是手动下载nvidia的二进制文件，直接进行安装。

但是这样会破坏一部分的glx链接，导致卸载的时候无法彻底恢复，结果就是系统因为卸载nvidia驱动而废掉，所以我推荐使用包管理器的方式安装nvidia驱动和cuda相关的东西，尽量不要手动修改。

需要安装的很少，只有五个包，不过会依赖很多nvidia的库，总量还是有一些的。

sudo apt install nvidia-cuda-toolkit nvidia-profiler nvidia-visual-profiler nvidia-cuda-doc nvidia-cuda-dev

nvcc是cuda的编译器，它目前只支持g++5，所以还需要安装g++5。

sudo apt install g++-5

然后，重启一下计算机。

这里有个小栗子，可以用来测试cuda是否能够成功编译和运行

将以下代码保存为 main.cu

#include <stdio.h>

__global__ void vector_add(const int *a, const int *b, int *c) {
 *c = *a + *b;
}

int main(void) {
 const int a = 2, b = 5;
 int c = 0;

 int *dev_a, *dev_b, *dev_c;

 cudaMalloc((void **)&dev_a, sizeof(int));
 cudaMalloc((void **)&dev_b, sizeof(int));
 cudaMalloc((void **)&dev_c, sizeof(int));

 cudaMemcpy(dev_a, &a, sizeof(int), cudaMemcpyHostToDevice);
 cudaMemcpy(dev_b, &b, sizeof(int), cudaMemcpyHostToDevice);

 vector_add<<<1, 1>>>(dev_a, dev_b, dev_c);

 cudaMemcpy(&c, dev_c, sizeof(int), cudaMemcpyDeviceToHost);

 printf("%d + %d = %d, Is that right?\n", a, b, c);

 cudaFree(dev_a);
 cudaFree(dev_b);
 cudaFree(dev_c);

 return 0;
}

编译:

nvcc main.cu

运行:

./a.out

如果一切顺利，在编译的时候就不会有报错，不过在我的环境下nvcc会有架构被弃用的警告，本着只要不error就算没事的原则，我们无视这条警告即可。

输出结果:

2 + 5 = 0, Is that right?

deepin待机后键盘和触摸板无法使用的解决方法

justforlxz — Sun, 24 Jun 2018 22:01:22 +0000

笔记本一直使用的bumblebee来省电，毕竟我也不想笔记本的电只够从一张桌子移动到另一张桌子，但是今天在调待机唤醒后dde-dock崩溃的问题，我需要切换到私有驱动下，因为笔记本使用bumblebee需要使用acpi的参数，否则会见图形就死。

一切准备就绪以后，我开始调试dde-dock，通过codedump已经知道崩溃在wifi列表为空时访问了first节点，但是当我开始测试修复的代码时，发生了很意外的事情，恢复待机以后键盘和触摸板无法使用了。

虽然之前我也偶尔会用用私有驱动，但是还没遇到过无法键盘和触摸板无法使用的情况。想到论坛好像也有人报了类似的问题，恢复待机以后无wifi和外置键盘无法使用，刚好可以趁这个机会调试一下。

/var/log/Xorg.0.log里看到了大量的synaptics错误，然后该模块被卸载，键盘则是没看到什么信息。

尝试重新modprobe synaptics模块，但是失败了，然后在/etc/modprobe.d/nvidia.conf里看到了几行配置。

# These aliases are defined in *all* nvidia modules.
# Duplicating them here sets higher precedence and ensures the selected
# module gets loaded instead of a random first match if more than one
# version is installed. See #798207.
#aliaspci:v000010DEd00000E00sv*sd*bc04sc80i00*nvidia
#aliaspci:v000010DEd00000AA3sv*sd*bc0Bsc40i00*nvidia
#aliaspci:v000010DEd*sv*sd*bc03sc02i00*nvidia
#aliaspci:v000010DEd*sv*sd*bc03sc00i00*nvidia

似乎是通配出错了，匹配到了键盘和触摸板，然后就无法使用了。刚好deepin 15.6升级了nvidia驱动，所以是现在才会出这个问题。

Dock插件开发<等待填坑>

justforlxz — Tue, 22 May 2018 21:22:12 +0000

从零构建 dde-dock 的插件
本教程将展示一个简单的 dde-dock 插件的开发过程，插件开发者可跟随此步骤为 dde-dock 创造出更多具有丰富功能的插件。

在本教程中，将创建一个可以实时显示用户家目录(~/)使用情况的小工具。

插件的工作原理
dde-dock 插件本质是一个按 Qt 插件标准所开发的共享库文件(so)。通过 dde-dock 预定的规范与提供的接口，共同完成 dde-dock 的功能扩展。

准备环境
插件的开发环境可以是任意的，只要是符合 Qt 插件规范及 dde-dock 插件规范的共享库文件，都可以被当作 dde-dock 插件载入。下面以 Qt + qmake 为例进行说明：

安装依赖
以 Deepin 15.5.1 环境为基础，至少先安装如下的包：

dde-dock-dev
qt5-qmake
qtbase5-dev-tools
libqt5core5a
libqt5widgets5
pkg-config

基本的项目结构
创建必需的项目目录与文件
插件名称叫做home_monitor，所以创建以下的目录结构：

home_monitor
├── home_monitor.json
├── homemonitorplugin.cpp
├── homemonitorplugin.h
└── home_monitor.pro

重构dde-session-ui

justforlxz — Sun, 11 Mar 2018 03:48:01 +0000

dde-session-ui里面包含了很多项目，是一个集合，但是其中的代码缺少合理的维护，以至于已经到了必须重构才能继续开发和维护，在支持AD域登录的时候，如果强制加上功能，代码会变得更加糟糕，所以和石博文一块重构了其中非常重要的UserWidget。

重构前的设计

重构前的dde-lock和lightdm-deepin-greeter是非常混乱的，处理逻辑都混杂在一块，虽然能看出有基本的结构，但是整体并未解耦。

重构后的设计

基于User类的处理
UserWidget负责提供对用户的处理，暴露出基本的currentUser和LogindUsers。
Lock和Greeter的Manager从UserWidget、SessionWidget中获取用户和用户的会话。
Manager只负责控件的位置和用户的验证。
背景修改为Manager提供模糊的壁纸，FullBackground只提供绘制。

重构以后用了大概原代码的1/3，启动速度也快了，感觉世界充满了美好… 就是重构历程太辛苦…

本次也发现了很多自身的问题，基础并没有学好，很多地方都可以使用更好的处理方式【就是管不住这手…】

使用DTK开发

justforlxz — Fri, 12 Jan 2018 03:05:26 +0000

在阅读本篇文章之前，你需要掌握基本的Qt/C++开发知识。

注意：本篇文章基于Deepin平台，其他平台请自行补充依赖关系。

先安装DTK的依赖关系。

sudo apt install libdtkwidget2 libdtkcore2

新建Qt项目，编辑pro文件，添加项目依赖。

CONFIG += c++14 link_pkgconfig
PKGCONFIG += dtkwidget

DTK目前有两个组件，一个是提供库功能的core，一个是提供控件的widget。

修改main.cpp,删除QApplication的相关内容，改为DApplication。

注意：使用DTK的组件，需要使用DTK的宏,根据使用的文件来选择对应的宏。

DWIDGET_USE_NAMESPACE
DCORE_USE_NAMESPACE

DTK使用了deepin自己的qt插件，需要在DApplication前调用。

DApplication::loadDXcbPlugin();
DApplication app(argc, argv);

DApplication中提供了很多方法来设置程序的各种信息，具体请看头文件的定义。

主窗口由DMainWindow提供，新建类，然后添加DMainWindow的头文件和DTKWIDGET的宏。

#include <DMainWindow>

DWIDGET_USE_NAMESPACE

然后修改继承关系，改为继承DMainWindow。DMainWindow提供了一些我们封装的方法。目前为止，该程序的界面已经符合Deepin程序的风格了，我们封装了一些其他控件，使其样式符合我们的风格，如果要在其他Qt程序中使用，也是同样的步骤，载入Qt插件，添加对应的头文件和DTK的宏。

开发topbar中的技术问题

justforlxz — Wed, 23 Aug 2017 00:54:56 +0000

这里记录了开发topbar中遇到的坑和一些问题。

使用Qt提供的qxcb方法注册阴影为dock类型，反而处于DESKTOP和NORMAL之间。其实当初并不是想设置为DOCK类型的，因为这样阴影也会在窗口上方，我希望的是阴影在普通程序下方，在桌面上方。今天曹哥来讲窗管的一些坑，讲到窗管是如何控制窗口的，我的阴影其实是被Qt注册成_NET_WM_STATE_BELOW了。
这里可以看到一些type的介绍。

在_NET_WM_STATE中一共有这么几个类型：

_NET_WM_STATE_MODAL, ATOM
_NET_WM_STATE_STICKY, ATOM
_NET_WM_STATE_MAXIMIZED_VERT, ATOM
_NET_WM_STATE_MAXIMIZED_HORZ, ATOM
_NET_WM_STATE_SHADED, ATOM
_NET_WM_STATE_SKIP_TASKBAR, ATOM
_NET_WM_STATE_SKIP_PAGER, ATOM
_NET_WM_STATE_HIDDEN, ATOM
_NET_WM_STATE_FULLSCREEN, ATOM
_NET_WM_STATE_ABOVE, ATOM
_NET_WM_STATE_BELOW, ATOM
_NET_WM_STATE_DEMANDS_ATTENTION, ATOM

如果程序被注册成_NET_WM_STATE_BELOW，则会被放置在DESKTOP之上的一层。不是很清楚Qt是出于什么策略，才把我的阴影注册为这个状态，反而是刚好满足了我的需求。

这要多谢曹哥了，我才终于明白了为什么会这样，以及以后如何正确的设置type。

debug了两天，只删了一行代码

justforlxz — Wed, 16 Aug 2017 10:25:39 +0000

前言：项目一定要留一些文档！！修bug前一定要知道所有的流程！！！

这两天一直在修一个用户切换的bug，众所周知，deepin的多用户切换一直都不是正常工作的，确切来说是压根没有正常工作，还好用户不是经常切换，不然早就收到一大波的报告了。

dde-session-ui项目中包含了以下软件：

dde-lock
dde-shutdown
dde-osd
lightdm-deepin-greeter
dde-switchtogreeter
dde-suspend-dialog
dde-warning-dialog
dde-welcome
dde-wm-chooser
dde-lowpower
dde-offline-upgrader

大部分项目根据名字就可以知道是做什么的，这是一个软件组的集合。
而dde-lock和lightdm-deepin-greeter二者有大量重复的功能和代码，这是它俩的工作性质决定的。

lightdm-deepin-greeter: display-manager启动的实体，登录的界面是它负责的。

dde-lock：用户层面的屏幕锁定，基于我们的设计，和lightdm-deepin-greeter是大致相同的布局。

而且都包含了用户密码的验证，用户的切换，但是二者工作的层面是不同的，为了方便切换，就有了dde-switchtogreeter，用来协调二者的工作，只需要提供用户名就可以切换。

然而，虽然这样的想法是很好的，可是当初并没有人写文档，随着人员的变动，现在公司应该没有一个人是比较完整了解整个的工作流程了，用户切换的bug也就这样被留下来了。

上次修复用户切换的问题，是发现登录以后lightdm-deepin-greeter没有退出，由于不是很清楚linux的登录流程，再加上代码中有不工作的退出代码，当时就改好了退出的问题，这样就引入了第二个问题，而这个问题，就导致了两天三个人在一直查找问题所在。

这次的问题是发现一直切换greeter，会导致Xorg一直在开新的display，这就很奇怪了，正常来说是不会一直创建才对。

最开始以为是dde-switchtogreeter的问题，毕竟切换是它在做，dde-switchtogreeter是单文件的c代码，代码没有任何的说明，真的是为切换而生，我从main函数开始自己走了好几遍的流程，一边看着d-feet的数据来验证，然而只发现了一个小问题，整个代码是没啥问题的。

最后在后端大佬的帮助下，知道了display-manager会自己退掉greeter，不需要自己退，然后我就想起来了以前改的地方，赶紧把退出代码删掉，重新编译，问题得到了解决。

如果我知道display-manager的工作流程，也许这个问题就不会拖两天了。

正常的流程在界面上却是bug

justforlxz — Mon, 14 Aug 2017 23:43:43 +0000

排查了一天，最后终于确认了流程，知道了问题所在，不得不说，dde-session-ui这个项目太需要一个文档了，要把工作流程写的非常详细才可以。

上午收到了一条新任务，是龙芯上新安装的系统需要输入两次密码才可以登录，没有错误提示。近期并没有什么太大的改动，无非是给龙芯也用上了简单重构过的dde-session-ui，怎么会导致这样的问题。

由于是新安装的系统才会发生，而且是现象一旦发生，就无法重现，这让我头有点大，怎么会有这样的神奇的事情，而且日志中很正常，没有收到message导致密码框被清空。我提交了一个添加了更多日志的，然后重装的龙芯的系统(龙芯重装一次要半个小时)，等重装完了，切换到tty去安装这个包，然后重启lightdm，让我输入密码回车以后，密码消失，我赶紧去看日志，但是日志中并没有我的输出，回车以后肯定会有的一行输出也没有(内心OS：What the fuck is that？)

我又回去看验证的流程，并没有发现有什么不对的地方，而且是近期才有的，我在自己电脑上使用了龙芯的编译参数，打了一个deb包，并没有发生和龙芯一样的情况（这里并不需要，既然是新安装的系统才会发生，在旧系统上是无法重现的）。

再然后我暂时没有管这个，先去修其他bug了。忙完以后，我去问了一下其他大佬，大佬给我提了几条让我去看看，是不是起了两个lightdm-deepin-greeter进程，确认一下使用的二进制是不是你加了log的。（然后我又重装龙芯了），之后确认了是我的二进制，也没有起两个进程。但是ps中有两行输出，我以为是起了两个，就让后端大佬看了一下，后端大佬告诉我说一个是shell的进程，一个是本体，还是只有一个进程存在的。我彻底懵逼了，然后后端大佬告诉我，是不是greeter进程写入什么了，之后的验证中内容已经存在，所以就不会重现了。

其实这个我也想过，但是没考虑太深，greeter并没有操作文件，但是大佬这么一说，我想到有一些dbus的调用，是有写入文件的，然后我把/var/lib/lightdm/lightdm-deepin-greeter目录给删除了，完美重现。

我的天啊，排查了快一天，居然是这个目录在新装的系统上没有，所以回车登录以后收到了来自dbus的switchToUser，界面重启导致的内容消失，根本不是收到了Message才被清空的，所以我的log也没有打印出来。

知道了如何重现，可是要怎么修复呢，似乎在greeter上并不能修复，只能去改dde-daemon中LockService，如果文件不存在，就不要发送userChanged的信号。（流程是读取这个文件的信息，和传入的参数进行对比，但是文件是空的，所以被认为不是同一个账户，就发送了信号，也导致了界面上重启，以后无法重现是因为里面已经有内容了）。

就这样，一个流程很正确，但是表现到界面上时就成了一个bug的问题被解决了。写下这篇内容是为了记录我如何解决对我来说很棘手的问题，其实这个问题并不是很困难，但是对整个工作的流程不是很熟悉，导致浪费了大量的时间在非关键点处理，有空要写一些文档了。

在deepin上使用dnsmasq来解决dns解析缓慢

justforlxz — Fri, 11 Aug 2017 06:07:26 +0000

其实这个问题影响并不是很大，只是稍微的增加一点点访问速度，缓存这东西有利有弊。

在写完这篇文章以后，我就不用dnsmasq了，现在用的是github上的Pcap_DNSProxy。用来防止dns污染的。

根据https://stackoverflow.com/questions/11020027/dns-caching-in-linux 中回答者提供的信息来看，linux发行版是不提供dns解析缓存的，上面提到的nscd也不在deepin的预装列表中，所以我们只能自己动手丰衣足食了。

首先安装口碑较好的dnsmasq，来为我们提供dns缓存。

sudo apt install dnsmasq

如果是deepin最新的2015.4.1版本中安装，安装结束会提醒一个错误，这个错误的解决办法来自https://stackoverflow.com/questions/16939306/i-cant-restart-my-dnsmasq-service-so-my-fog-server-wont-work.
这个错误似乎是因为/usr/share/dns/root.ds文件更新后结构导致的错误。

编辑/etc/init.d/dnsmasq，并找到

ROOT_DS="/usr/share/dns/root.ds"

if [ -f $ROOT_DS ]; then
 DNSMASQ_OPTS="$DNSMASQ_OPTS `sed -e s/". IN DS "/--trust-anchor=.,/ -e s/" "/,/g $ROOT_DS | tr '\n' ' '`" 
fi

修改为

ROOT_DS="/usr/share/dns/root.ds"

if [ -f $ROOT_DS ]; then
 DNSMASQ_OPTS="$DNSMASQ_OPTS `sed -e s/".*IN[[:space:]]DS[[:space:]]"/--trust-anchor=.,/ -e s/"[[:space:]]"/,/g $ROOT_DS | tr '\n' ' '`" 
fi

当错误解决以后，我们手动重启一下dnsmasq的systemd服务。

sudo systemctl restart dnsmasq

deepin的/etc/resolv.conf来自/etc/NetworkManager/resolv.conf.是一个软连接。我采取的行为是删除这个文件，重新创建。

sudo rm /etc/resolv.conf

sudo vim /etc/resolv.conf

然后写入本地地址当做dns地址。

nameserver 127.0.0.1

dnsmasq是一个本地的dns和dhcp服务器，当我们在上面成功启动dnsmasq以后，个人系统中就已经在提供dns服务了，所以本机使用回环地址来表明dns服务器就是本机，所有的dns查询都会发送到本机的dnsmasq中。

如果需要额外添加dns服务器，做法来自https://wiki.archlinux.org/index.php/Dnsmasq#More_than_three_nameservers.

创建一个 /etc/resolv.dnsmasq.conf，写入其他dns服务器的地址。

nameserver 114.114.114.114

然后编辑 /etc/dnsmasq.conf,找到resolv-file字段，改为

resolv-file=/etc/resolv.dnsmasq.conf

然后重启dnsmasq。

验证的话通过dig命令。

dig blog.mkacg.com

通过执行两次来判断，Query time在第二次查询是为0 msec。

topbar PPA

justforlxz — Thu, 20 Jul 2017 05:37:51 +0000

自己搭了一个仓库，提供deepin-topbar及相关依赖的包。

I created a repository,provide deepin-topbar and dependencies.

也许需要安装dirmngr

maybe you need install dirmngr

追加内容到/etc/apt/sources.list

Append content to /etc/apt/sources.list

deb [arch=amd64] https://packages.mkacg.com panda main

导入key

import key

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 3BBF73EE77F2FB2A

刷新列表，进行安装

then, refresh list and install

sudo apt update && sudo apt install deepin-topbar

用Flex和Bison自制“五仁”语言

deepin 社区官方博客 — Wed, 04 May 2016 06:00:00 +0000

“五仁”官方名称：zScript
变量使用关键字"var"进行声明，变量本身无类型

变量声明可放在源码中任何位置，可在任何位置被调用，例如，var a在源码中最后一行，也可以在第一行使用变量a
每条语句的结尾必须是';‘或换行符(后面准备改成强制使用’;‘结尾)
目前支持的数据类型：int、double、bool、string、list、tuple、object 、undefined
函数也是object类型
string的定义为 '’ 或 "" 中所包裹的内容，支持C和JavaScript风格的字符转义
支持的运算符： =、+、-、、/、%、&、|、~、^、&&、||、+=、-=、=、/=、%=、&=、|=、~=、^=、&&=、||=、!、>、<、=、==、===、!=、!==、++、–
支持匿名函数，函数闭包，多值返回
支持的分支结构：if else
支持的循环结构：goto while for（后面准备加入do while、foreach）
while for 循环结构中使用break跳出循环，continue立马开始执行下一次循环，break和continue可组合使用例如：break, break 则可以直接跳出两层循环，组合使用时continue只能放在末尾
支持switch case语句，可枚举int bool string undefined

Flex(Lexical Analyzar)

Lex是一个产生词法分析器的工具(最早是Eric Emerson Schmidt和Mike Lesk制作）是许多UNIX系统的标准词法分析器（lexical analyzer）产生程序，而且这个工具所作的行为被详列为POSIX标准的一部分。而Flex就是由Vern Paxon实现的Lex
FLex读进一个代表词法分析器规则的输入字符串流，然后输出C/C++语言的词法分析器源代码。
wiki：https://en .wik i p e dia.o r g/w i ki/F l ex _%28lex ical _an a ly s er _g e n erat o r %29

Flex的文件结构

文件分成三个区块，均以一个只有两个百分比符号（%%）的单行来分隔，如下：

定义区域 %% 规则区域 %% C/C++代码区

定义区块是用来定义宏以及导入C写成的头文件所在区块。在这里面也可以写一些C代码，这一些代码会被复制到产生出来的C源代码的开头部分。
规则区块是最重要的区块；这里将样式与C的陈述（statement）串连在一起。这一些样式都是正则表达式。当lexer看到输入里面有合乎给定的样式时，则会操作相对应的C代码。这就是flex运作的基础。
C代码区块的内容会原封不动的照搬到产生出来的C源代码里面。

小例子

%{
#include
%}
number [0-9]+
%option noyywrap
%% // 第一部分结束
{number} {
printf("number: %s\n", yytext);
}
%% // 第二部分结束
int main()
{
yylex();
return 0;
}

%option noyywrap用于指明未定义yywrap函数，此函数用于在文件（或输入）的末尾调用。如果函数的返回值是1，就停止解析。否则等待输入后继续解析注：正则表达式是使用单个字符串来描述、匹配一系列字符串的规则

wiki：h ttp s://zh.wiki p e di a.o rg/w iki/%E6%AD %A3%E5%88%99%E 8%A1%A8%E 8%BE%BE%E5%BC%8F

Bison

Bison是GNU版本的Yacc（Lexical Analyzar），用于做语法分析，它与Yacc兼容
参考手册：ht t p://www.gn u .o r g /so f twa re /biso n /manual/b i so n .html 中译版：htt p ://bl o g.c s dn.ne t /s i r o u ni 2003/ar ticl e /d e tail s /400672
wiki：h t tps://en.wi kipe d ia.o rg/wi k i /GNU_bis on

Bison的文件结构

和Flex一样，也分为三个部分
分别是声明、语法规则和代码段，使用%%分开

定义区域 %% 规则区域 %% C/C++代码区

第一部分和Flex一样，用于存放终结符的声明、符号优先级和符号类型等定义
第二部分用来定义文法规则
第三部分也是用来存放C/C++代码

来个小例子

%{
#include
#define YYSTYPE int
void yyerror(char const *);
int yylex(void);
%}
%token NUMBER
%debug
%%
start: { printf("yylval = %d\n", yylval);}
| NUMBER {
printf("NUMBER %d\n", yylval);
}
start NUMBER {
printf("start NUMBER %d\n", yylval);
}
;
%%
void yyerror(char const *msg)
{
printf("error: %s\n", msg);
}
int yylex()
{
printf("&gt;&gt;&gt;");
char str[10] = {};
if(scanf("%s\n", str) == EOF)
return 0;
int number = atoi(str);
printf("%d\n", number);
yylval = number;
return NUMBER;
}
int main()
{
return yyparse();
}

%token用于定义一个终结符
%debug指定bison在生成的代码中加入debug输出（和bison的-t参数一样）
yyerror在分析过程中有语法错误时被调用
yylex用于给分析器返回token（在生成的代码中自动被调用）注：终结符是指文法规则中不能再被分解的最小单位，非终结符则是相反的概念。

例如上面的文法规则中“start”就是非终结符，NUMBER就是一个终结符。

wiki：h tt ps://zh.w i k ipe d i a.o rg/wik i /%E7%B5%82%E7%B5%90%E 7%AC%A 6%E 8%88%87%E 9%9 D %9 E %E7%BB%88%E7%B5%90%E 7%AC%A6#

语法介绍

变量的定义

变量使用关键字“var”进行定义。

zScript提供了两种形式的变量定义语句。

1.直接定义的形式，该语句的一般形式为：

var 标识符;

该语句的含义是：定义变量名为“标识符”的变量。例如：

var a;

该语句的作用是：定义一个名为“a”的变量。 2.定义同时给变量初始化赋值，该语句的一般形式为：

var 标识符 = 表达式;

该语句的含义是：定义变量名为“标识符”的变量，且给变量赋值为表达式的结果。例如：

var a = 1 + 2;

该语句的作用是：定义一个名为“a”的变量，且赋值为3。 “var”关键字可同时定义多个变量，每个变量之间使用符号“,”分割。

匿名函数的定义

匿名函数定义的一般形式为：

(形参列表) {
语句组
}

该语句的含义是：生成一个函数对象，例如：

(a) {
console.log(a);
}

该语句的作用是：定义一个函数，它有一个名为“a”的形参，执行此函数会将a的值打印到屏幕上。形参列表，可为空、一个、多个，多个形参之间使用“,”分割。

数组的定义

数组定义的一般形式为：

var a = [表达式1, 表达式2, ...];

该语句的含义是：生成一个数组，数组元素为中括号中表达式的结果。例如：

var a = [1, 2, 3];

该语句的作用是：定义一个包含三个元素的数组，元素的值分别为1、2、3，然后赋值给变量a；数组使用“[”“]”定义，中间内容可以为空、一个表达式、多个表达式，多个表达式之间使用“,”隔开。

a = a[0];

取数组元素语法和C语言一样，都是中括号中写入数组下标。

选择控制语句

一个选择结构，包括一组或若干组操作，每组操作称为一个分支。通过选择控制语句可以实现选择结构。选择控制语句包括if语句、switch语句及起辅助控制作用的break语句。

If语句用于计算给定的表达式，根据表达式的值是否为假，决定是否执行某一组操作。

Switch语句首先求解一个表达式，然后根据计算结果的值，从哈希表中查询该从哪一组操作开始执行。

Break语句用于switch结构中，用于终止当前switch结构的执行。

if语句

zScript提供了两种形式的if语句。

1.单if子句的if语句。该if语句的一般形式为：

if(表达式)
{
语句组
}

该语句的含义是：只有表达式的值为非零值时，才执行其内部的语句组。例如：

if ( a &gt; b )
{
console.log(“hello”);
}

该语句的作用是：当a的值大于b的值时（此时，“a>b”的值为真，为非假值），在屏幕上显示“hello”；否则，不显示“hello”。 2.带else子句的if语句。该if语句的一般形式为：

if ( 表达式 )
{
语句组1
} else {
语句组2
}

该语句的含义是：当表达式的值为非假时，执行语句组1，而不执行语句组2；否则，即表达式的值为假时，执行语句组2，而不执行语句组1。例如：

if ( a &gt; b )
{
console.log(“hello1”);
} else {
console.log(“hello2”);
}

该语句的作用是：若a的值大于b的值（此时“a>b”为真，为非假值），则在屏幕上显示“hello1”，而不显示“hello2”；否则，即表达式的值为假时，显示“hello2”，而不显示“hello1”。

switch语句

Switch语句与if语句一样，也可以实现分支选择。但if语句是判断一个表达式的值是否为假，决定是否执行某个分支；而switch语句是计算一个表达式的值，根据计算结果，从哈希表查询从哪个分支开始执行代码。Switch语句的一般形式为：

switch( 表达式 )
{
case 常量1：
语句组1
case 常量2：
语句组2
...
case 常量n：
语句组n
default:
语句组 n + 1
}

switch语句的执行过程：

1.求解“表达式”的值；
2.如果“表达式”的值与某个case后面的“常量”的值相同，则从这里开始顺序执行语句。结果switch执行有两种形式：一是遇到break语句为止；二是未遇到break语句，则程序依次执行完所有语句组。
3.如果“表达式”的值与任何一个case后面的“常量”的值都不相同，当有default子句时，则执行default后面的语句，如果没有default子句，则结束switch。

其中break的一般形式为

break;

循环控制语句

while语句

while语句的一般形式为

while( 表达式 )
{
循环体
}

while语句的执行过程：

1.求解小括号中表达式的值。如果表达式的值为真，转第2步；否则转第3步。
2.执行循环体，然后转第1步。
3.执行while语句后面的语句。

小括号中表达式的值是否为假，决定着循环体是终止还是继续循环。因此，该表达式的值为循环条件。while循环语句的执行特点是，先判断循环条件是否成立，然后决定是否执行循环体。

当while语句的循环体只包含一条语句时，包含该循环体的“{}”可以省略。

for语句

在两种循环语句中，for语句最为灵活。for语句的一般形式为：

for (表达式1; 表达式2; 表达式3)
{
循环体
}

for语句的执行过程：

1.求解表达式1的值。
2.求解表达式2的值，若其值为假，则结束循环，转第4步；若其值为真，则执行循环体。
3.求解表达式3。
4.结束循环。

对象的定义

对象定义的一般形式为：

{
属性名1: 属性的值,
属性名2: 属性的值,
...
属性名n: 属性的值,
属性名n+1: 属性的值
}

例如：

var object = {
name: "张三",
age: 18
};

变量object即是一个对象，它包含两个属性。注：当对一个对象不存在的属性赋值时会将此属性加入到对象中，例如：

object.sex = '男';

对象object中就会多出一个“sex”属性。

My Life

justforlxz — Fri, 25 Mar 2016 03:56:08 +0000

这是我用markdown写的第一篇文章(水文)，先来个自我介绍吧，我是小竹，对没错，是小竹，不是竹子，不是竹酱，更不是竹基。

我玩linux应该有五六年了吧，初二的时候接触的，不过很多年都保持在换各种发行版上，并没有真正意义的玩。上了大学以后，接触的更多了，玩的也更嗨了。
现在也用上arch+btrfs+uefi了，各种叼炸天。
irc里面也经常学习【看别人装逼。
依旧是英语渣渣，数学渣渣，看到win32api，我直接放弃win编程了，我的智商也就玩玩wpf了。
下面就贴几张我的日常截图。

My Computer info

kirigayaloveyousei@linuserOS: Arch LinuxKernel: x86_64 Linux 4.4.5-1-ARCHackages: 1092Shell: zsh 5.2Resolution: 1366x768WM: Mutter(DeepinGala)WM Theme: AdwaitaGTK Theme: Arc-OSX [GTK2/3]Icon Theme: deepinFont: Noto Sans CJK SC Regular 10CPU: Intel Core i5-4210U CPU @ 2.7GHzRAM: 1980MiB / 3861MiB

Planet deepin | 简体中文

deepin-ports SIG 周报 (2026-06-05)

本周进展

deepin-ports 维护

其它

下周规划

RVA23 仓库 部分已推迟

RISC-V 转译应用适配 部分已推迟

关键设备适配

其它 部分已推迟

deepin-ports SIG 周报 (2026-05-22)

本周进展

关键设备适配 进展预估 60%

deepin-ports 维护

其它

下周规划

RVA23 仓库 部分已推迟

RISC-V 转译应用适配 部分已推迟

关键设备适配

其它 部分已推迟

deepin-ports SIG 周报 (2026-05-15)

本周进展

deepin-ports 维护

其它

下周规划

RVA23 仓库 部分已推迟

RISC-V 转译应用适配 部分已推迟

关键设备适配

其它 部分已推迟

deepin-ports SIG 周报 (2026-05-08)

本周进展

RVA23 仓库 进展预估 55%

关键设备适配 进展预估 50%

deepin-ports 维护

其它

下周规划

RVA23 仓库 部分已推迟

RISC-V 转译应用适配 部分已推迟

关键设备适配

其它 部分已推迟

deepin-ports SIG 周报 (2026-04-30)

本周进展

RVA23 仓库 进展预估 55%

deepin-ports 维护

其它

下周规划

RVA23 仓库 部分已推迟

RISC-V 转译应用适配 部分已推迟

其它 部分已推迟

deepin-ports SIG 周报 (2026-04-17)

本周进展

RVA23 仓库 进展预估 50%

关键设备适配 进展预估 40%

其它

下周规划

RVA23 仓库 部分已推迟

RISC-V 转译应用适配 部分已推迟

其它 部分已推迟

deepin-ports SIG 周报 (2026-04-10)

本周进展

RVA23 仓库 进展预估 50%

deepin-ports 维护

其它

下周规划

RVA23 仓库 部分已推迟

关键设备适配 部分已推迟

RISC-V 转译应用适配 部分已推迟

其它 部分已推迟

deepin-ports SIG 周报 (2026-04-02)

本周进展

RVA23 仓库 进展预估 50%

deepin-ports 维护

下周规划

RVA23 仓库 部分已推迟

关键设备适配 部分已推迟

RISC-V 转译应用适配 部分已推迟

其它 部分已推迟

deepin-ports SIG 周报 (2026-03-27)

本周进展

RVA23 仓库 进展预估 45%

RVA23 仓库部分已推迟

RISC-V 转译应用适配部分已推迟

其它部分已推迟

关键设备适配进展预估 60%

RVA23 仓库部分已推迟

RISC-V 转译应用适配部分已推迟

其它部分已推迟

RVA23 仓库部分已推迟

RISC-V 转译应用适配部分已推迟

其它部分已推迟

RVA23 仓库进展预估 55%

关键设备适配进展预估 50%

RVA23 仓库部分已推迟

RISC-V 转译应用适配部分已推迟

其它部分已推迟

RVA23 仓库进展预估 55%

RVA23 仓库部分已推迟

RISC-V 转译应用适配部分已推迟

其它部分已推迟

RVA23 仓库进展预估 50%

关键设备适配进展预估 40%

RVA23 仓库部分已推迟

RISC-V 转译应用适配部分已推迟

其它部分已推迟

RVA23 仓库进展预估 50%

RVA23 仓库部分已推迟

关键设备适配部分已推迟

RISC-V 转译应用适配部分已推迟

其它部分已推迟

RVA23 仓库进展预估 50%

RVA23 仓库部分已推迟

关键设备适配部分已推迟

RISC-V 转译应用适配部分已推迟

其它部分已推迟

RVA23 仓库进展预估 45%

RVA23 仓库部分已推迟

关键设备适配部分已推迟

RISC-V 转译应用适配部分已推迟

其它部分已推迟

RVA23 仓库进展预估 45%

RVA23 仓库部分已推迟

关键设备适配部分已推迟

RISC-V 转译应用适配部分已推迟

其它部分已推迟

RVA23 仓库进展预估 45%

关键设备适配进展预估 40%

RVA23 仓库部分已推迟

关键设备适配部分已推迟

RISC-V 转译应用适配部分已推迟

其它部分已推迟

RVA23 仓库进展预估 40%

关键设备适配进展预估 40%

RVA23 仓库部分已推迟

关键设备适配部分已推迟

RISC-V 转译应用适配部分已推迟

其它部分已推迟

RVA23 仓库部分已推迟

关键设备适配部分已推迟

RISC-V 转译应用适配部分已推迟

其它部分已推迟

RVA23 仓库进展预估 32%

RVA23 仓库部分已推迟

关键设备适配部分已推迟

RISC-V 转译应用适配部分已推迟

其它部分已推迟

RVA23 仓库进展预估 30%

关键设备适配部分已推迟

RISC-V 转译应用适配部分已推迟

其它部分已推迟