Month: July 2026

在 KDE Plasma 从 X11 迁移到 Wayland 之后，一些曾经依赖 X11 窗口属性的工具会逐渐失去作用。KDocker 就是典型例子：它可以在 X11 环境中把普通窗口“塞进”系统托盘，但面对原生 Wayland 窗口时，这种外部包装方式已经不再可靠。 本文记录一次完整迁移过程，目标是让两个应用在 KDE Plasma Wayland 下获得统一的托盘行为： 涉及的应用类型包括： 整个迁移过程遵循三个原则： 一、旧方案的问题在哪里 旧方案的结构大致如下： KDocker 在 X11 下通常通过窗口类、窗口 ID 和窗口管理协议操作应用窗口，达到以下效果： 这种方式在 X11 中相对直接，但 Wayland 的安全模型不同： 因此，在原生 Wayland 环境中继续维护 KDocker，不仅效果不稳定，还会引入额外的 XWayland 依赖和窗口识别问题。 正确方向不是继续修补 KDocker，而是： 二、迁移顺序非常重要 这类迁移最危险的操作顺序是： 一旦原有 Desktop entry 直接调用 KDocker，先卸载软件包就会让应用入口失效。 …

在药物研发、结构生物学和生物信息学研究中，经常会遇到一个重要问题： 一个分子是否可能与某种蛋白质结合？如果能够结合，它大概会以什么姿势进入蛋白质的结合区域？ 实验方法当然可以回答这些问题，但蛋白质结构解析、结合实验和功能验证通常需要较多时间、设备和成本。因此，在真正开展实验之前，研究人员往往会先使用计算机进行初步预测。 AutoDock Vina，就是这一领域最常见的工具之一。 它能够根据受体和配体的三维结构，在计算机中模拟两者可能的结合方式，并为不同结合姿势提供近似评分。虽然它不能代替实验，却可以帮助研究人员缩小候选范围、发现可能的结合位点，并为后续实验提供参考。 一、什么是 AutoDock Vina AutoDock Vina，通常简称为 Vina，是一款用于分子对接的软件。 所谓分子对接，可以简单理解为： 让计算机尝试把一个分子放入另一个分子的表面或口袋中，并寻找看起来最合理的结合方式。 在典型的分子对接任务中，通常包含两个主要对象： Vina 会尝试改变配体的位置、方向以及内部构象，并计算不同姿势的评分，最终输出一组预测结果。 这些结果可以用来判断： 因此，Vina 常被应用于虚拟筛选、药物发现、蛋白质功能研究和候选分子排序。 二、分子对接可以理解成“钥匙和锁”吗 介绍分子对接时，经常会使用“钥匙和锁”的比喻。 蛋白质像一把锁，配体像一把钥匙。如果钥匙的形状适合锁孔，它就可能进入其中并产生结合。 这个比喻容易理解，但真实情况比钥匙和锁复杂得多。 首先，蛋白质并不是完全静止的刚性结构。它会振动、弯曲，也可能在不同构象之间变化。配体同样不是固定形状，许多化学键可以旋转，因此同一个分子可能呈现出多种三维构象。 其次，分子之间的结合不仅取决于形状是否匹配，还受到许多物理和化学作用影响，例如： 因此，Vina 所做的并不是简单寻找一个“能塞进去的位置”，而是在庞大的构象空间中寻找相对合理的空间排列。 三、Vina 是怎样工作的 Vina 的核心工作可以概括为两个部分： 1. 搜索结合姿势 在对接开始前，需要指定一个搜索区域，也就是所谓的对接盒。 对接盒通常是一个三维长方体，用来告诉 Vina： 只在这片区域内寻找配体可能的结合位置。 如果蛋白质的活性口袋已经明确，对接盒可以直接覆盖该口袋。如果结合位点未知，也可以设置较大的区域，甚至进行全蛋白表面搜索。 在搜索过程中，Vina 会不断调整配体的： 每一次调整都代表一个候选姿势。 由于可能的组合数量极其庞大，软件不可能枚举所有情况，因此必须使用启发式搜索算法，在有限时间内尽量找到更优的解。 2. 计算结合评分 找到候选姿势后，Vina 会通过经验评分函数估计该姿势是否合理。 输出结果中，通常会看到类似这样的数值： 一般来说，数值越负，代表该姿势在 Vina …

切换到 KDE Plasma Wayland 后，有时会遇到这样一种现象：每次登录桌面，系统都会自动弹出一个屏幕共享选择窗口，要求选择显示器，并显示类似以下名称： 窗口底部还可能出现： 乍看之下，很容易怀疑 KDE Portal、PipeWire 或 Wayland 配置出现了问题。但在这次排查中，真正的问题并不在 KDE，而是一个基于 Electron 的聊天客户端在启动时错误地申请了屏幕捕获权限。 本文记录完整的判断过程、定位方法以及最终解决方案。 一、现象：切换到 Wayland 后，每次开机都要求共享屏幕 系统环境大致如下： 窗口要求用户选择： 即使完全没有进行视频会议、录屏或远程桌面操作，这个窗口仍然会自动出现。 这种现象通常说明： 某个登录自启动应用，在启动过程中调用了 Wayland 的屏幕捕获接口。 二、为什么切换到 Wayland 后才出现 X11 和 Wayland 对屏幕内容访问的安全模型完全不同。 X11 的方式 在传统 X11 环境中，桌面应用通常可以直接读取屏幕内容。录屏软件、截图工具、远程桌面和视频会议程序不一定需要经过系统级授权。 这也意味着，理论上任何连接到 X Server 的程序都可能读取其他窗口内容。 Wayland 的方式 Wayland 不允许普通应用随意读取整个屏幕。 应用如果需要： 通常必须通过以下组件： 因此，切换到 Wayland …

在高分辨率显示器上使用 Linux 桌面时，缩放一直是一个绕不开的问题。 屏幕分辨率越来越高，27 英寸 4K 显示器已经十分常见。如果完全按照 100% 比例显示，文字、图标和窗口控件往往会小得难以使用；但如果简单地把画面放大，又可能出现字体模糊、窗口尺寸异常、应用界面比例不一致等问题。 在传统 X11 环境中，这类问题长期存在。相比之下，Wayland 下的软件缩放已经能够呈现出一种非常接近原生的观感：界面不仅变大了，而且依然清晰、协调，甚至很难意识到系统正在进行缩放。 这种体验上的变化，并不只是“字体变大了一点”，而是整个桌面坐标体系和窗口绘制方式发生了改变。 一、高分屏真正的问题不是分辨率，而是像素密度 一块 27 英寸的 4K 显示器拥有 3840×2160 个物理像素。 如果桌面仍然按照传统 96 DPI 左右的尺寸逻辑显示，那么一个原本设计为 100 像素宽的按钮，在高像素密度屏幕上会变得非常小。虽然画面更加精细，但实际操作体验反而可能下降。 因此，高分屏系统需要同时处理两个概念： 例如，在 200% 缩放下，一个逻辑像素可以对应横向和纵向各两个物理像素。应用仍然认为自己绘制的是一个正常尺寸的窗口，但显示器会使用更多物理像素呈现它。 理想情况下，缩放后的窗口应该只是“更精细”，而不是“被拉大”。 Wayland 的优势，正是在于它能够更加系统地处理逻辑尺寸和物理尺寸之间的关系。 二、X11 缩放为什么经常显得不自然 X11 诞生于高分屏普及之前。它的许多核心设计都建立在较为固定的像素坐标基础上。 在 X11 环境中，窗口的位置和大小通常更接近物理像素概念。例如，一个窗口可能被明确放置在某个像素坐标，并拥有固定的像素宽度和高度。 当系统需要进行缩放时，桌面环境往往只能通过多个相互独立的机制进行补偿，例如： 这些方法并不是完全无效，但容易产生不一致。 典型问题包括： 因此，X11 下的高分屏配置往往像是在多个独立系统之间反复协调。 最终可以得到“能用”的结果，但很难真正做到统一。 三、Wayland 使用逻辑坐标管理桌面 …

引言 KDE Plasma的窗口规则功能非常强大。 它可以让指定应用自动： 在X11环境中建立的大量窗口规则，切换到Wayland后可能出现： 原因通常集中在两个方面： 一、X11中的WM_CLASS X11窗口通常具有 WM_CLASS 属性。 可以使用： 点击窗口后获取类似： KDE窗口规则会使用这些信息识别应用。 规则文件中可能出现： 其中精确匹配意味着窗口身份必须完全一致。 二、Wayland中没有传统WM_CLASS 原生Wayland窗口不使用X11的 WM_CLASS。 应用会向合成器提供其他身份信息，例如应用ID。KWin会将这些信息映射到窗口规则界面中，仍可能显示为“窗口类”，但来源已经不同。 因此，同一个程序可能出现三种身份： 应用升级、切换启动参数或更换后端后，旧规则就可能无法匹配。 三、Electron和Chromium应用尤其容易变化 Electron和Chromium程序的窗口身份可能受到以下因素影响： 例如，同一个浏览器窗口可能分别呈现： 如果规则使用精确匹配： 任何细微变化都可能导致规则失效。 四、重新采集窗口属性 Wayland下不应继续依赖 xprop 获取原生窗口身份。 更合适的方法是： 然后点击目标窗口。 采集时应记录： 如果应用同时支持Wayland和XWayland，应确认当前窗口实际运行在哪种模式。 五、不要过度依赖窗口标题 窗口标题通常包含动态内容，例如： 如果规则使用精确标题匹配，很容易失效。 更合理的匹配优先级通常是： 六、Wayland使用逻辑坐标 假设显示器物理分辨率为： 缩放为： 逻辑桌面尺寸约为： Wayland下，KWin窗口位置和大小通常基于逻辑像素。 如果旧X11规则中写着： 这些值可能是按照4K物理像素设计的。 迁移到1.5倍缩放的Wayland后，同样数值会被解释为逻辑像素，窗口可能变得非常大，甚至超出屏幕边界。 七、如何换算旧坐标 简单情况下，可以使用： 例如： 原尺寸： …

引言 在Linux桌面切换到Wayland后，经常会看到名为： 的进程。 这容易引发一个误解：既然已经使用Wayland，为什么系统里仍然运行X11组件？是否应该删除XWayland，才能获得“纯Wayland”环境？ 答案通常是否定的。 XWayland不是完整的X11桌面会话，而是Wayland环境中的兼容层。保留它，并不会阻止原生Wayland应用运行，反而可以保证大量尚未完成迁移的应用继续正常使用。 一、XWayland是什么 传统X11应用需要连接X Server。 Wayland桌面没有传统意义上的全局X Server，因此需要一个兼容服务接收X11协议，再把窗口交给Wayland合成器显示。 这个兼容服务就是XWayland。 运行路径大致如下： 在KDE Plasma中，Wayland合成器是KWin。 因此，XWayland只是KWin管理下的一个兼容组件。 二、XWayland不等于X11桌面会话 完整X11桌面会话通常运行： Wayland会话运行： 即使Wayland会话中存在： 当前桌面仍然是Wayland。 可以检查： 如果结果为： 并且运行的是： 就说明整个桌面由Wayland管理。 三、为什么XWayland进程可能一直存在 某些桌面环境会在登录后提前启动XWayland，而不是等第一个X11应用出现后再启动。 因此： 只能证明兼容服务已经准备好，不能单独证明当前一定有X11应用正在运行。 判断是否存在实际X11客户端，还需要： 四、哪些应用可能仍然需要XWayland 1. 老旧X11程序 部分多年未更新的应用没有原生Wayland支持，只能连接X Server。 2. 部分Electron程序 较新的Electron可以使用Wayland，但一些应用可能： 3. Wine和特殊兼容程序 部分Wine应用、游戏启动器和旧图形工具仍可能通过XWayland工作。 4. 输入法兼容路径 某些旧程序仍通过XIM输入中文或日文。此时需要： 并依赖XWayland提供X11环境。 5. 旧自动化或窗口工具 某些脚本依赖： 它们可能只能操作XWayland窗口。 五、保留XWayland是否会降低Wayland安全性 …

引言 在KDE Plasma从X11切换到Wayland后，Fcitx5输入法经常出现一种看似矛盾的状态： 问题的根源在于：Wayland、XWayland、Qt、GTK和XIM使用的输入法路径并不完全相同。 正确配置不应只是把所有变量都全局导出，而应明确每一条输入路径的用途。 一、原生Wayland输入法如何工作 在Wayland环境中，输入法通常通过Wayland输入法协议与合成器协作。 KDE Plasma中的合成器是KWin。 Fcitx5应在： 中启用。 这样KWin可以把Fcitx5作为Wayland输入法客户端启动，并为它提供需要的输入法协议连接。 这部分不是传统的XIM环境变量机制。 二、XWayland应用仍需要XMODIFIERS 旧X11应用运行在XWayland中时，通常仍然通过XIM与输入法通信。 因此需要： 注意模块名称是： 而不是： Fcitx5是程序的代际名称，但XIM和工具包模块使用的名字仍然是 fcitx。 三、为什么使用environment.d 推荐的用户级配置路径是： 例如创建： 内容： environment.d 是systemd提供的正式用户环境配置机制。 它适合Wayland桌面的原因包括： 修改后通常需要注销重新登录或重启，才能让新会话中的程序获得变量。 四、为什么不推荐全局设置GTK_IM_MODULE 传统配置经常包含： 这在X11环境中非常常见。 但在现代Wayland环境中，原生GTK应用可以通过Wayland输入法协议与Fcitx5配合。全局强制工具包模块，可能让原生Wayland应用绕过更合适的协议路径。 潜在问题包括： 因此，不应仅为了让变量“看起来完整”而全局设置。 五、为什么不推荐全局设置QT_IM_MODULE 同样，传统Qt配置常见： 但KDE原生Wayland应用通常应优先通过KWin和Wayland输入法协议工作。 全局强制 QT_IM_MODULE 可能导致： 更合理的原则是： 六、按应用设置兼容变量 某个旧Qt应用无法输入时，可以单独启动： 某个旧GTK应用无法输入时，可以使用： 如果应用通过桌面文件启动，可以复制相应 .desktop 文件到： 再修改 Exec=： 这样不会影响整个Wayland会话。 …

引言 长期使用Linux桌面的用户，对 xinput 通常并不陌生。 在X11环境中，可以使用它查看鼠标、触控板和键盘： 也可以修改属性： 然而切换到Wayland后，原先有效的命令可能完全没有作用。即使 xinput list 仍能输出一些设备，它看到的也通常只是XWayland兼容层，而不是整个桌面的真实输入设备状态。 这种变化不是工具失效，而是输入架构发生了根本改变。 一、X11下的输入模型 在传统X11桌面中，X Server是整个图形会话的核心。 键盘和鼠标事件大致经过： 应用程序可以向X Server查询： xinput 本质上就是一个X11客户端。它通过X Input Extension读取和修改X Server中的设备属性。 因此，X11下常见配置包括： 或者： 二、Wayland改变了控制边界 Wayland并不是一个替代X Server的单一程序，而是一套协议。 在Wayland桌面中，真正管理屏幕、窗口和输入设备的是合成器。 KDE Plasma中的合成器是： 输入事件大致经过： 应用程序不能再像X11时代那样自由读取所有全局输入信息。 普通Wayland应用通常无法： 这些限制是Wayland安全模型的一部分。 三、为什么Wayland下xinput仍然存在 Wayland桌面通常会启动XWayland，用于运行旧X11应用。 XWayland相当于在Wayland环境中提供一个兼容X Server。 因此可以形成两条路径： 以及： 此时执行： 看到的是XWayland内部的逻辑设备，而不是KWin直接管理的全部真实输入设备。 修改XWayland中的属性，最多只影响X11兼容应用，通常无法改变原生Wayland应用中的鼠标行为。 四、libinput也不是统一配置中心 另一个常见误解是：Wayland使用libinput，所以直接修改libinput即可。 libinput主要负责： 但libinput本身不负责维护整个桌面的用户配置文件。 不同桌面合成器会分别决定： 在KDE Plasma中，用户配置最终由KWin应用。 …

引言 在 KDE Plasma Wayland 中开启“自然滚动”后，鼠标滚轮方向可能完全没有变化。 系统设置界面显示选项已经启用，配置文件中也可能存在： 但浏览器和文件管理器仍然按照传统方向滚动。 这种现象不一定是 KDE 没有保存配置，也不一定是 libinput 不支持自然滚动。更常见的原因是：设置写到了错误的逻辑设备节点。 一、一个鼠标不一定只有一个输入节点 Linux通过 /dev/input/event* 暴露输入设备。 一个普通USB鼠标可能只有一个指针节点，但无线鼠标、蓝牙鼠标和多功能接收器经常生成多个设备： 这些名称看起来相似，但用途完全不同。 其中可能分别负责： KDE会按设备名称、vendor ID、product ID保存设置。如果自然滚动配置写到了 Consumer Control 节点，而真正滚轮来自另一个 Mouse节点，实际滚动方向就不会变化。 二、为什么设置界面容易选错设备 系统设置通常会列出多个相似设备名称。用户看到“2.4G Mouse”后开启自然滚动，但当前真正产生滚轮事件的设备可能叫： 两者甚至可能来自两个不同的USB接收器。 KWin保存的配置段类似： 例如： 如果实际鼠标对应： 前面的配置就不会应用到当前设备。 三、不要单独相信 libinput list-devices 常见检查方式是： 输出中可能看到： 但这并不能证明 KWin 当前没有启用自然滚动。 libinput list-devices 创建的是自己的 libinput 上下文，显示的是设备默认值或该上下文中的状态。KWin在Wayland会话中拥有独立的运行时配置。 因此应区分： KDE …

引言 从 X11 切换到 Wayland，表面上只是更换登录界面中的会话类型，实际上却涉及整个 Linux 桌面输入、显示和窗口管理机制的变化。 在 X11 环境中，应用程序可以直接获取窗口、键盘、鼠标和屏幕信息；而在 Wayland 环境中，这些能力大多由桌面合成器统一控制。对于 KDE Plasma 来说，这个合成器就是 KWin。 因此，完成登录并看到桌面，并不代表迁移已经结束。鼠标、输入法、显示缩放、窗口规则、绘图板、截图、录屏和旧自动化脚本，都可能需要重新检查。 本文整理一套较完整的 KDE Plasma Wayland 迁移检查思路。 一、先确认当前会话确实是 Wayland 最基本的检查是： 正常结果应为： 也可以检查 KWin 进程： 通常会看到： 其中，kwin_wayland 表示 Plasma 当前运行在 Wayland 模式；Xwayland 是兼容旧 X11 应用的服务，并不代表系统仍然运行在完整的 X11 桌面会话中。 二、重新检查输入设备 Wayland 下，鼠标和触控板不再由 xinput 直接管理，而是由 KWin 调用 libinput 处理。 …