前言 Waydroid 可以在 Linux 桌面环境中运行接近原生体验的 Android 系统。完成基础部署后，通常可以正常启动 Android、连接网络、登录 Google Play，并安装一部分应用。 但在 x86-64 Linux 主机上，经常会遇到一种典型问题： 这类问题的核心通常不在网络、Google 账号或 Play 商店，而在于 CPU 指令集架构不匹配。 本文完整记录一次在 Arch Linux、KDE Wayland 和 Waydroid Android 13 环境中，为 Waydroid 安装 Intel Houdini ARM 转译层的过程，包括： 文中的用户名、主机名、个人目录和时间戳均已替换或泛化。 一、问题现象 Waydroid 已经完成以下配置： 然而，一些常用阅读类应用在 Google Play 中显示： 此应用与当前设备不兼容。 首先检查 Linux 主机架构： 输出： 再检查 Waydroid …
引言 Waydroid 的多窗口模式很有吸引力。 启用后，Android 应用可以像普通 Linux 软件一样，以独立窗口出现在 KDE Plasma 桌面中。应用能够单独移动、最小化、切换和管理，不必始终面对一个完整的 Android 桌面。 理论上，这正是桌面 Linux 使用 Android 应用时最自然的体验。 然而，在某些 KDE Plasma Wayland、显卡驱动和 Waydroid 图形栈组合中，多窗口模式可能触发严重兼容问题。本次测试中，打开一个 Android 应用后，整个 KDE 桌面立即黑屏，Waydroid 随后异常退出。 最终只能关闭多窗口模式，恢复完整 Android 主界面。 一、完整界面模式与多窗口模式的区别 Waydroid 常见的两种使用方式如下。 完整界面模式 执行： 会打开一个完整的 Android 桌面。 它包含： 这种模式更接近平板电脑或安卓虚拟机。 多窗口模式 设置： 重启 session 后，Android 应用会被映射成独立的 Linux 桌面窗口。 例如： …
引言 Waydroid 已经能够启动，Android 桌面也能正常显示，Google 应用和系统组件均存在，但状态始终显示： Android 内部的网络接口处于 UP 状态，却没有 IPv4 地址、默认路由和 DNS 配置。浏览器、Google Play 和其他联网应用自然全部不可用。 这类问题很容易被误判为 Android 镜像损坏、Waydroid 安装不完整，甚至被建议重新初始化或重装。实际上，本次故障最终与 Android 镜像、LXC 容器和 Waydroid 本身都没有直接关系，而是宿主机防火墙没有正确放行 Waydroid 的虚拟网络接口。 整个排查过程的关键，不是反复修改配置，而是逐层确认 DHCP 数据包究竟消失在哪里。 一、故障现象 宿主环境为： Waydroid 启动后可以观察到： Android 系统本身已经完成启动： 图形界面、启动器、系统服务和应用管理器均可使用。 宿主侧也能看到： 但 Android 内部没有： 这说明问题集中在 DHCP 获取阶段。 二、不要被 FROZEN 状态误导 Waydroid 空闲时可能将容器置于冻结状态： 这并不等于容器崩溃，也不等于安装损坏。 只有在进行实时网络测试、抓包或进入 …
许多电脑游戏只提供 Windows 版本，但这并不意味着它们一定无法在 Linux 系统上运行。 目前，Linux 玩家最常使用的方案之一，是 Steam 提供的 Proton。它可以让大量 Windows 游戏直接在 Linux 环境中运行，而且通常不需要另外安装完整的 Windows 系统。 Proton 是什么 Proton 是 Valve 为 Steam 开发和维护的一套游戏兼容工具。 它以 Wine 为基础，并结合了多种专门面向游戏的组件和补丁，用来处理 Windows 游戏依赖的系统接口、图形接口、声音、输入设备和网络功能。 从结构上可以简单理解为： Windows 游戏 → Proton 兼容层 → Linux 系统 → 硬件 游戏仍然是原本的 Windows 版本，但其调用的 Windows 功能会由 Proton 转换或重新实现。 它不是虚拟机 Proton 与传统虚拟机有明显区别。 …
在 KDE Plasma 从 X11 迁移到 Wayland 之后，一些曾经依赖 X11 窗口属性的工具会逐渐失去作用。KDocker 就是典型例子：它可以在 X11 环境中把普通窗口“塞进”系统托盘，但面对原生 Wayland 窗口时，这种外部包装方式已经不再可靠。 本文记录一次完整迁移过程，目标是让两个应用在 KDE Plasma Wayland 下获得统一的托盘行为： 涉及的应用类型包括： 整个迁移过程遵循三个原则： 一、旧方案的问题在哪里 旧方案的结构大致如下： KDocker 在 X11 下通常通过窗口类、窗口 ID 和窗口管理协议操作应用窗口，达到以下效果： 这种方式在 X11 中相对直接，但 Wayland 的安全模型不同： 因此，在原生 Wayland 环境中继续维护 KDocker，不仅效果不稳定，还会引入额外的 XWayland 依赖和窗口识别问题。 正确方向不是继续修补 KDocker，而是： 二、迁移顺序非常重要 这类迁移最危险的操作顺序是： 一旦原有 Desktop entry 直接调用 KDocker，先卸载软件包就会让应用入口失效。 …
切换到 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会话。 …