回顾

DDE 在 v15 时期，使用 Mutter 作为带合成器的窗管，以及 Metacity

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 组件之上：

• https://codereview.qt-project.org/c/qt/qtwayland/+/598596
• https://codereview.qt-project.org/c/qt/qtwayland/+/599732

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。

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）进行讨论。

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）进行讨论。

技术背景

顾名思义，内存压缩就是压缩内存，节省内存空间。相信对于搞技术的人来说，压缩这个词并不陌生，一想到这个词，我们首先想到的是压缩可以降低占用空间，使同样的空间可以存放更多的东西。 内存无论多大，总是会有不够用的时候，或者说我们总是想在尽量低的成本控制下，达到系统最优，这个时候还是有必要引入诸如内存压缩的功能来优化系统内存占用。当系统内存紧张的时候，会将文件页丢弃或回写回磁盘（如果是脏页），还可能会触发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本身存在一些缺陷或问题:

1. 如果开启当zswap满交换出backing store的功能, 由于需要将zswap里的内存按LRU顺序解压再swap out, 这就要求内存分配器支持LRU功能。
2. 如果不开启当zswap满交换出backing store的功能, 和zRam是类似的。

zRram

zRram即压缩的内存， 使用内存模拟block device的做法。实际不会写到块设备中去，只会压缩后写到模拟的块设备中，其实也就是还是在RAM中，只是通过压缩了。由于压缩和解压缩的速度远比读写IO好，因此在移动终端设备广泛被应用。zRam是基于RAM的block device, 一般swap priority会比较高。只有当其满，系统才会考虑其他的swap devices。当然这个优先级用户可以配置。

zRram本身存在一些缺陷或问题:

1. zRam大小是可灵活配置的, 那是不是配置越大越好呢? 如果不是,配置多大是最合适的呢?
2. 使用zRam可能会在低内存场景由于频繁的内存压缩导致kswapd进程占CPU高, 怎样改善?
3. 增大了zRam配置,对系统内存碎片是否有影响?

要利用好zRam功能, 并不是简单地配置了就OK了, 还需要对各种场景和问题都做好处理, 才能发挥最优的效果。

zCache

zCache是oracle提出的一种实现文件页压缩技术，也是memory与block dev之间的一层“cache”,与zswap比较接近，但zcache目前压缩的是文件页，而zSwap和zRAM压缩是匿名页。

zcache本身存在一些缺陷或问题:

1. 有些文件页可能本身是压缩的内容, 这时可能无法再进行压缩了；
2. zCache目前无法使用zsmalloc, 如果使用zbud,压缩率较低；
3. 使用的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分别怎样组合最合适呢? 下面总结了一下, 具体原因可以看上面介绍的时候各类型的特点。

zRAM技术原理

zRam内存压缩技术是目前移动终端广泛使用的内存压缩技术。

软件框架

下图展示了内存管理大体的框架， 内存压缩技术处于内存回收memory reclaim部分中。

再具体到zRam, 它的软件架构可以分为3部分：数据流操作，内存压缩算法 ，zram驱动。

实现原理

Zram内存压缩技术本质上就是以时间换空间。通过CPU压缩、解压缩的开销换取更大的可用内存空间。

我们主要描述清楚下面这2个问题： 1.什么时候会进行内存压缩？ 2.进行内存压缩/解压缩的流程是怎样的？

进行内存压缩的时机：

1. Kswapd场景：kswapd是内核内存回收线程， 当内存watermark低于low水线时会被唤醒工作， 其到内存watermark不小于high水线。
2. 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

其他参数

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的一些缺陷, 怎么去改善呢?

1. zRam大小是可灵活配置的, 那是不是配置越大越好呢? 如果不是配置多大是最合适的呢? zRam大小的配置比较灵活, 如果zRam配置过大, 后台缓存了应用过多, 这也是有可能会影响前台应用使用的流畅度。另外, zRam配置越大, 也需要关注系统的内存碎片化情。因此zRam并不是配置越大越好,具体的大小需要根据内存总大小及系统负载情况考虑及实测而定。

2. 使用zRam,可能会存在低内存场景由于频繁的内存压缩导致kswapd进程占CPU高, 怎样改善? zRam本质就是以时间换空间, 在低内存的情况下, 肯定会比较频繁地回收内存, 这时kswapd进程是比较活跃的, 再加上通过压缩内存, 会更加消耗CPU资源。改善这种情况方法也比较多, 比如, 可以使用更优的压缩算法, 区别使用场景, 后台不影响用户使用的场景异步进行深度内存压缩, 与用户体验相关的场景同步适当减少内存压缩, 通过增加文件页的回收比例加快内存回收等等。

3. 增大了zRam配置,对系统内存碎片是否有影响? 使用zRam是有可能导致系统内存碎片变得更严重的, 特别是zsmalloc分配不支持可移动内存类型的时候。新版的内核zsmalloc已经支持可移动类型分配的， 但由于增大了zRam,结合android手机的使用特点, 仍然会有可能导致系统内存碎片较严重的情况,因些内存碎片问题也是需要重点关注的。解决系统内存碎片的方法也比较多, 可以结合具体的原因及场景进行优化。

参考资料

Linux内存压缩浅析之原理

zRAM内存压缩技术原理与应用

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）进行讨论。

简述

在上一篇浅析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命令激活配置

配置详解

基础操作

音频

注释： SOUND_POWER_SAVE_ON_AC/BAT 指的是SOUND_POWER_SAVE_ON_AC 和 SOUND_POWER_SAVE_ON_BAT

电池保养

这些参数用于设置笔记本电脑主/内部电池（BAT0）和辅助电池（BAT1）的充电阈值。启动充电阈值表示在连接充电器时，电池充电水平低于该值时将开始充电。停止充电阈值表示在充电器连接时，电池充电水平超过该值时将停止充电。这些阈值始终具有较低的可用电池容量，因此默认情况下禁用这些设置，并且必须通过删除前导 # 来显式启用这些设置。

光驱

硬盘

注释：DISK_IOSCHED 如果使用是NVME设备时，最好使用无IO调度程序来减少CPU开销（none和noop）

文件系统

图形显卡

这些参数允许用户调整 Intel GPU 和 AMD GPU 在交流电和电池模式下的性能和电源管理行为。在配置这些参数时，建议参考硬件规格和运行 tlp-stat -g 查看可用频率。

kernel

不建议关闭watchdog 否则可能导致内核崩溃后无法自动重启和内核调试

网络

这些参数允许用户配置Wi-Fi的电源保存模式和控制Wake-on-LAN（LAN唤醒）功能。

平台

其实如果能使用S3休眠那就更好，不过现在很多厂商并不支持S3,所以如果能用S2那就用S2吧。

处理器

这些参数允许用户配置 CPU 的性能和功耗特性，包括缩放驱动程序操作模式、调节器、频率范围、能耗/性能策略、P 状态范围、提升功能以及 HWP 动态提升功能。

部分电脑的BIOS会干预PState 所以需要检查自己的CPU是否支持

无线设备

这些参数允许用户配置在系统启动、关闭或更改电源状态时如何处理内置的蓝牙、Wi-Fi 和 WWAN 设备。可通过设置禁用或启用这些设备，以及在何种条件下执行这些操作。

无线配置向导（自动化配置）

这些参数允许用户配置在特定事件触发时如何处理内置的蓝牙、Wi-Fi 和 WWAN 设备。用户可以根据 LAN、Wi-Fi 或 WWAN 的连接状态、对接或取消对接等事件来启用或禁用这些设备。

PCIE电源配置

这些参数允许用户配置与 PCIe 设备相关的运行时电源管理和 ASPM 等功能。用户可以根据电源来源、设备地址、驱动程序等来调整这些设置，以实现更好的功耗管理。（建议不要对nvidia驱动进行调整，可能会引发意外）

USB

Trace Mode

TLP_DEBUG="arg bat disk lock nm path pm ps rf run sysfs udev usb"

结语

我们对于系统的优化不仅于此，现阶段tlp的配置策略仅对于部分有能力的用户公开，后续经过充分的测试和调优之后，会提供几份默认的配置给普通用户使用。并将来将这些配置文件GUI化，集成于深度定制项目中，为用户提供更为方便直观的操作体验。

从这一阶段对于电源优化的探索可以看出，deepin系统的电源管理方案优化不仅是为了解决用户反馈的问题，更是一种对用户需求的回应和尊重。在未来，deepin系统将继续秉持用户至上的原则，不断提升系统的性能和用户体验，为广大用户提供更加优秀的操作系统产品。

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 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: [email protected]
                     |       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是一个用于跟踪分析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	

工作原理

如图1所示，X11其主要有两种通信方式，在同一个计算机内主要使用unix domain socket进行通信；在不同计算机之间使用TCP/IP通信。只需要“截获”通信消息，将其转为易于读取的格式输出即可达到监控目的。这是xtrace工作的基本原理。

如下图2是X11窗口创建的基本流程，因为篇幅限制，图中只绘制了基础的请求和事件，但X11协议远比图中绘制的复杂，笔者在此只介绍一下基础的协议交互模型，方便在读者在查看xtrace追踪日志时有基础的认知。

总之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请求通信，然后打印输出

相关的代码调用堆栈如下：

Breakpoint 1, startline (c=0x4f8270, d=TO_SERVER, format=0x417a71 "%04x:%3u: Request(%hhu): %s ") at parse.c:52
52              if( (print_timestamps || print_reltimestamps)
(gdb) bt
#0  startline (c=0x4f8270, d=TO_SERVER, format=0x417a71 "%04x:%3u: Request(%hhu): %s ") at parse.c:52
#1  0x000000000040b5f5 in print_client_request (c=0x4f8270, bigrequest=false) at parse.c:1692
#2  0x000000000040cc2d in parse_client (c=0x4f8270) at parse.c:1996
#3  0x0000000000403b4a in mainqueue (listener=4) at main.c:406
#4  0x00000000004045d4 in main (argc=4, argv=0x7fffffffdef8) at main.c:706
(gdb) c
Continuing.

Breakpoint 1, startline (c=0x4f8270, d=TO_CLIENT, format=0x417b32 "%04x:%u: Reply to %s: ") at parse.c:52
52              if( (print_timestamps || print_reltimestamps)
(gdb) bt
#0  startline (c=0x4f8270, d=TO_CLIENT, format=0x417b32 "%04x:%u: Reply to %s: ") at parse.c:52
#1  0x000000000040c1f3 in print_server_reply (c=0x4f8270) at parse.c:1859
#2  0x000000000040d0e5 in parse_server (c=0x4f8270) at parse.c:2064
#3  0x00000000004035ed in mainqueue (listener=4) at main.c:336
#4  0x00000000004045d4 in main (argc=4, argv=0x7fffffffdef8) at main.c:706

// connect socket
Breakpoint 2, generateSocketName (addr=0x7fffffffdd30, display=9) at x11common.c:114
114             snprintf(addr->sun_path,sizeof(addr->sun_path),"/tmp/.X11-unix/X%d",display);
(gdb) p display 
$5 = 9
(gdb) c
Continuing.
[Detaching after fork from child process 7682]
Got connection from unknown(local)

Breakpoint 2, generateSocketName (addr=0x7fffffffd9d0, display=0) at x11common.c:114
114             snprintf(addr->sun_path,sizeof(addr->sun_path),"/tmp/.X11-unix/X%d",display);
(gdb) p display 
$6 = 0
(gdb) bt
#0  generateSocketName (addr=0x7fffffffd9d0, display=0) at x11common.c:114
#1  0x0000000000404c92 in connectToServer (displayname=0x7fffffffe363 ":0", family=1, hostname=0x0, display=0) at x11client.c:77
#2  0x0000000000402766 in acceptConnection (listener=3) at main.c:95
#3  0x0000000000403edd in mainqueue (listener=3) at main.c:452
#4  0x00000000004045d4 in main (argc=2, argv=0x7fffffffdf18) at main.c:706
(gdb) 

协议分析

xtrace通过拦截X11协议通信来进行分析。它捕获传输到X服务器的请求以及服务器对这些请求的响应，将他们解析化以日志输出的形式打印出来。所以本质来说协议分析指的是X11协议交互分析，需要对 X11相关的协议做到非常了解，即每个协议有什么功能，在xcb中是如何处理，在xserver中又是如何处理。受限于篇幅，笔者在此不会阐述所有的协议分析，而是拿我们平时常用的一些软件做一些分析和介绍。

上述表格中只是介绍了常见部分的协议，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