KDE Plasma Wayland 下配置 Fcitx5:environment.d、KWin 与 XWayland

引言 在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会话。 …

从 xinput 到 KWin:Wayland 下 Linux 输入设备管理发生了什么

引言 长期使用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 Wayland 自然滚动不生效:问题可能不在设置,而在设备节点

引言 在 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 …

KDE Plasma 从 X11 迁移到 Wayland:真正需要检查什么

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

Waydroid:在 Linux 桌面上运行安卓应用的现实方案

Linux 桌面已经能够完成绝大多数日常工作,但仍然存在一个长期缺口:许多服务只提供 Android 或 iOS 客户端,没有原生 Linux 版本。 一些应用可以通过网页版替代,但也有不少程序依赖移动端通知、扫码、触摸界面、Android 专用协议或移动平台生态。过去遇到这类需求时,通常只能准备一台实体安卓设备,或者在 Linux 中运行 Android 虚拟机。 Waydroid 提供了第三种方案:直接在 Linux 容器中运行一套完整的 Android 系统,并将其中的应用整合进 Linux 桌面。 截至 2026 年 7 月,Waydroid 官方最新版本为 1.6.3,当前系统镜像基于 Android 13 和 LineageOS 20。Arch Linux 也已经将 Waydroid 直接收入官方 Extra 仓库,不再需要通过 AUR 安装。 Waydroid 是什么 Waydroid 并不是传统意义上的安卓模拟器。 传统模拟器往往需要模拟一套完整硬件,例如虚拟 CPU、显卡、主板、存储设备和网络设备。Android 系统运行在虚拟硬件之上,Linux 主机与 …

KDE 在 X11 与 Wayland 下的窗口坐标为什么完全不同

从 KDE Plasma 的 X11 会话迁移到 Wayland 会话后,很多用户都会遇到一个看似奇怪的问题: 原本在 X11 下设置好的窗口位置、窗口大小、屏幕分区和精确坐标,到了 Wayland 下几乎全部失效。即使显示器没有更换,分辨率仍然是同一个数值,窗口规则中的坐标也往往无法直接沿用。 这并不一定是配置错误,而是因为 X11 和 Wayland 对“屏幕坐标”和“窗口尺寸”的定义本来就不一样。 X11 更接近物理像素坐标 在传统的 X11 环境下,窗口管理器通常基于 X Server 提供的根窗口坐标系工作。 假设显示器的分辨率是: 那么整个桌面的坐标范围通常也接近: 如果希望一个窗口占据屏幕右半边,可以将窗口设置为: 在这种模式下,窗口坐标与屏幕物理像素往往比较接近。即使系统调整了字体 DPI,或者应用内部进行了界面缩放,窗口管理器看到的桌面坐标空间通常仍然保持原始分辨率。 因此,在 X11 环境中,使用固定坐标管理窗口相对直观。许多基于 wmctrl、xdotool 或 KWin 窗口规则的配置,也都是按照这种思路设计的。 Wayland 使用逻辑坐标 Wayland 的设计不同。 在 Wayland 环境中,系统会区分至少三种概念: 其中,KWin 在管理窗口位置和大小时,主要使用的是逻辑坐标,而不是直接使用显示器的物理像素。 例如,一台显示器的物理分辨率仍然是: 如果系统缩放设置为 150%,那么 …

Arch Linux KDE HiDPI 环境下统一桌面与登录界面鼠标光标的完整记录

在 HiDPI 显示器上使用 Linux 桌面环境时,鼠标光标的大小和图标主题有时并不会在所有阶段保持一致。尤其是在 KDE Plasma、SDDM 登录管理器、X11 会话共同存在的环境中,可能会出现这样的现象: 本文记录一次针对特定 HiDPI 硬件环境的光标统一定制过程。设备信息已脱敏,仅保留与显示效果相关的参数。 环境背景 系统环境大致如下: 该显示器属于 4K HiDPI 场景。如果系统整体按约 150% 缩放理解,常见 24 像素光标按比例放大后约为: 因此,最终目标不是随意放大光标,而是让光标大小与 HiDPI 缩放比例保持一致。 问题现象 最初 KDE 桌面和 SDDM 登录界面都已设置为光标大小 32。使用一段时间后,32 在 27 英寸 4K 屏幕上显得略小,因此决定将光标大小调整为 36。 调整后,桌面光标明显变大,但登录界面仍然存在不一致现象: 这说明系统中至少存在多个阶段的光标来源: 只修改 KDE 桌面设置,无法完全覆盖 SDDM 和系统默认阶段。 第一步:确认 KDE 桌面光标配置 KDE 用户会话的光标设置位于: …

克隆树莓派系统后,如何拆分两台设备的系统身份

背景 一套已经配置好的树莓派系统被完整复制到另一张存储卡上,随后分别在两台树莓派设备上启动。这样做可以节省大量重复配置时间,尤其适合系统中已经预先配置好远程访问、网络脚本、代理服务、Web 服务和若干常驻服务的情况。 不过,完整克隆系统也会带来一个明显问题:两台设备虽然硬件不同,但系统内部身份可能完全相同。 如果不处理,后续可能出现: 因此,在两台设备正式长期运行前,需要先把系统身份拆分开。 克隆系统后需要处理哪些身份信息 克隆系统后,至少需要检查和处理以下内容: 其中,最基础的三项是: 这三项分别对应: 只改主机名是不够的。如果 machine-id 和 SSH Host Key 仍然相同,两台设备在系统层面和安全身份层面仍然带有克隆痕迹。 第一次只改主机名为什么失败 一开始使用了常规方式修改主机名: 并同步修改: 当时看起来已经成功,但重启后主机名又恢复成旧值。 这说明问题并不在 hostnamectl 本身,而是系统启动过程中还有其他组件在覆盖主机名。 进一步检查发现,这套系统启用了 cloud-init。在该类系统中,主机名可能不是只由 /etc/hostname 决定,而是还会受到启动分区中的 cloud-init 配置影响。 关键位置包括: 如果启动分区的 user-data 中仍然写着旧主机名,同时 cloud-init 没有设置为保留当前主机名,那么重启后系统可能再次把主机名改回旧值。 因此,正确做法不是只改 /etc/hostname,而是要同时处理 cloud-init 的源头配置。 正确修改第一台设备主机名 假设第一台设备的新主机名为: 在 root 用户下,可以一次性执行: 重启后确认: 目标状态是: 这样,主机名才算真正持久修改成功。 重新生成 machine-id …

使用 Raspberry Pi Imager 建立分区后,通过 rsync 还原树莓派系统备份

背景 树莓派系统备份有两种常见方式:一种是直接使用镜像工具进行整卡复制,另一种是以目录形式保存完整 Linux 根文件系统。后者的优点是灵活,可以在不同容量的 SD 卡之间迁移,也方便排除临时文件、伪文件系统和缓存内容。 本次操作的目标是:使用 Raspberry Pi 官方写盘工具先写入一个新的可启动系统,让它自动建立 SD 卡分区结构;然后保留这个分区结构,删除新系统文件,再把已有的完整系统备份同步进去。最后修改新 SD 卡的 UUID,使系统能够正常启动。 这种方式适合以下场景: 基本思路 整个流程可以概括为: 其中最关键的地方是:还原文件之后,不能继续使用旧备份里的 UUID。必须把 fstab 和 cmdline.txt 中的 UUID 改成当前 SD 卡实际分区的 UUID。 事前确认 假设: 其中: 备份目录应当是完整的 Linux 根文件系统,顶层通常能看到: 如果备份使用的是较新的 Raspberry Pi OS 或 Ubuntu for Raspberry Pi,启动文件通常位于: 对应地,启动分区应挂载到: 第一步:用 Raspberry Pi Imager 写入基础系统 …

KDE Akonadi 登录阶段启动超时的排查与修复:一次由 kalendarac 引发的竞态问题

背景 某台 Arch Linux KDE Plasma 桌面系统在登录后检查用户级 systemd 服务状态时,发现曾经出现过 Akonadi 相关失败记录。Akonadi 是 KDE PIM 体系中的个人信息管理后端,常被 KMail、Kontact、KOrganizer、KAddressBook、日历提醒、联系人、邮件索引等组件使用。 问题的表面现象比较迷惑: 一开始能看到 Akonadi 相关失败;但随后执行: 又显示: 也就是说,systemd 认为某次 Akonadi 启动失败了,但 Akonadi 本身后来又确实运行起来了。 这类问题如果直接重建 Akonadi 数据库,很容易扩大风险。更合理的处理方式是先确认失败链路,再做最小可回退修复。 初始现象 用户级日志中可以看到类似记录: Akonadi 使用内置 MariaDB/MySQL 后端。日志中 mysqld 被 systemd 杀掉,说明失败并不是单纯的前端组件问题,而是 Akonadi 启动流程中包含的数据库进程被一并终止了。 系统级 unit 内容类似: 最初可疑点是 TimeoutSec=5sec。Akonadi 登录阶段启动时需要拉起 MariaDB、初始化数据库、注册 D-Bus …