从 KDE Plasma 的 X11 会话迁移到 Wayland 会话后，很多用户都会遇到一个看似奇怪的问题：
原本在 X11 下设置好的窗口位置、窗口大小、屏幕分区和精确坐标，到了 Wayland 下几乎全部失效。即使显示器没有更换，分辨率仍然是同一个数值，窗口规则中的坐标也往往无法直接沿用。
这并不一定是配置错误，而是因为 X11 和 Wayland 对“屏幕坐标”和“窗口尺寸”的定义本来就不一样。
X11 更接近物理像素坐标
在传统的 X11 环境下，窗口管理器通常基于 X Server 提供的根窗口坐标系工作。
假设显示器的分辨率是：
3840 × 2160
那么整个桌面的坐标范围通常也接近：
x = 0 ～ 3839
y = 0 ～ 2159
如果希望一个窗口占据屏幕右半边，可以将窗口设置为：
位置：1920, 0
大小：1920 × 2160
在这种模式下，窗口坐标与屏幕物理像素往往比较接近。即使系统调整了字体 DPI，或者应用内部进行了界面缩放，窗口管理器看到的桌面坐标空间通常仍然保持原始分辨率。
因此，在 X11 环境中，使用固定坐标管理窗口相对直观。许多基于 wmctrl、xdotool 或 KWin 窗口规则的配置，也都是按照这种思路设计的。
Wayland 使用逻辑坐标
Wayland 的设计不同。
在 Wayland 环境中，系统会区分至少三种概念：
- 显示器的物理分辨率
- 桌面的逻辑分辨率
- 应用程序实际渲染的缓冲区分辨率
其中，KWin 在管理窗口位置和大小时，主要使用的是逻辑坐标，而不是直接使用显示器的物理像素。
例如，一台显示器的物理分辨率仍然是：
3840 × 2160
如果系统缩放设置为 150%，那么 KWin 使用的逻辑桌面尺寸大约会变成：
2560 × 1440
计算方式可以简单理解为：
3840 ÷ 1.5 = 2560
2160 ÷ 1.5 = 1440
因此，在 Wayland 的 150% 缩放环境中，让窗口占据屏幕右半边时，参数应该接近：
位置：1280, 0
大小：1280 × 1440
而不是 X11 下常用的：
位置：1920, 0
大小：1920 × 2160
两组数值看起来差别很大，但在屏幕上的视觉效果可能是相同的。
物理分辨率并没有改变
需要特别说明的是，缩放并不会真的把显示器从 3840×2160 改成 2560×1440。
显示器依然以原始物理分辨率输出，面板上的像素数量也没有发生变化。改变的是 KWin 用来描述桌面空间的逻辑尺寸。
可以将它理解为：
物理分辨率：3840 × 2160
缩放比例：150%
逻辑分辨率：2560 × 1440
应用程序依然可以使用高分辨率缓冲区绘制文字和图像，因此画面不会简单地退化成低分辨率。只是窗口的位置、大小、边界和鼠标坐标，通常按照逻辑像素计算。
这正是 Wayland 高 DPI 支持的核心机制之一。
常见缩放比例对应的逻辑尺寸
以 3840×2160 显示器为例，不同缩放比例下的逻辑桌面尺寸大致如下：
| 缩放比例 | 逻辑桌面尺寸 |
|---|---|
| 100% | 3840×2160 |
| 125% | 3072×1728 |
| 150% | 2560×1440 |
| 175% | 约 2194×1234 |
| 200% | 1920×1080 |
其中，100%、150% 和 200% 的计算结果比较整齐。
125% 和 175% 这类分数缩放更容易出现取整问题，因为一个逻辑像素不再对应整数个物理像素。
例如在 150% 缩放下：
1 个逻辑像素 = 1.5 个物理像素
窗口坐标通常只能使用整数，但物理像素换算后的结果可能不是整数，因此系统必须进行舍入。
分数缩放可能产生一像素误差
在分数缩放环境中，经常会出现以下现象：
- 窗口边缘相差一个像素
- 相邻窗口之间出现细小缝隙
- 窗口规则恢复后位置略有偏移
- 截图区域与窗口边界不完全一致
- 鼠标坐标与物理像素不能简单一一对应
- 应用在不同缩放比例的显示器之间移动时大小发生变化
这些问题并不一定表示 KWin 计算错误，而可能只是整数逻辑坐标与分数物理像素之间无法完全对应。
在多显示器环境中，这种情况会更加明显。
例如，一台显示器使用 100% 缩放，另一台使用 150% 缩放。窗口从一块屏幕移动到另一块屏幕时，窗口对应的缩放比例、渲染倍率和逻辑尺寸都可能发生变化。
XWayland 应用会更复杂
Wayland 会话中并不一定所有程序都是原生 Wayland 应用。
一些旧程序仍然通过 XWayland 运行。XWayland 相当于在 Wayland 环境中提供一个兼容层，让传统 X11 应用继续工作。
这类程序可能同时涉及：
- X11 坐标
- Wayland 逻辑坐标
- KWin 的输出缩放
- 应用自身的 DPI 缩放
因此，同一个窗口规则在原生 Wayland 程序和 XWayland 程序上，可能表现得并不完全一致。
某些应用还可能出现模糊、尺寸异常、位置偏移或缩放重复的问题。这些现象往往不是单一配置导致的，而是多层坐标转换共同产生的结果。
为什么旧的窗口规则不能直接复用
从 X11 切换到 Wayland 后，以下配置通常需要重新检查：
- 窗口固定位置
- 窗口固定尺寸
- 左右半屏布局
- 多显示器窗口分配
- KWin 窗口规则
- 自动化窗口脚本
- 截图区域
- 数位板映射区域
- 远程桌面坐标
- 鼠标自动化脚本
如果原来的规则直接写死了物理像素坐标，那么在 Wayland 分数缩放环境中，几乎必然会产生偏差。
简单地将旧数值继续沿用，通常不会得到相同结果。
正确的做法是先确认当前桌面的逻辑尺寸，再重新计算窗口位置和大小。
如何重新计算窗口尺寸
最基础的换算公式是：
逻辑尺寸 = 物理尺寸 ÷ 缩放比例
例如：
物理宽度：3840
缩放比例：150%，也就是 1.5
逻辑宽度：3840 ÷ 1.5 = 2560
如果窗口需要占据右半屏：
窗口宽度：2560 ÷ 2 = 1280
窗口横坐标：1280
因此参数为：
位置：1280, 0
大小：1280 × 1440
不过，对于 125% 或 175% 这样的缩放比例，结果可能包含小数。实际使用时还要考虑 KWin 的取整方式、面板占用空间和窗口边框。
工作区域不一定等于屏幕尺寸
即使已经正确计算出逻辑分辨率，窗口仍然可能无法完全按照预期贴合屏幕。
原因是 KWin 还会区分：
- 整个屏幕区域
- 可用工作区域
- 面板保留区域
- 窗口装饰区域
- 最大化区域
例如，屏幕逻辑高度是 1440，但底部面板占用了 48 个逻辑像素，那么普通窗口可用的高度可能只有：
1440 - 48 = 1392
如果窗口规则仍然强制设置为 1440 高，窗口可能被面板遮挡，也可能被 KWin 自动调整。
因此，设置窗口大小时，不能只看显示器分辨率，还要确认面板是否设置为始终可见、自动隐藏或允许窗口覆盖。
实际迁移时的建议
从 X11 迁移到 Wayland 后，最好不要直接复制旧的窗口坐标配置。
更合理的处理方式是：
- 确认显示器物理分辨率。
- 确认每块显示器的缩放比例。
- 计算 KWin 使用的逻辑分辨率。
- 确认面板占用的逻辑空间。
- 分别测试原生 Wayland 与 XWayland 应用。
- 重新记录窗口位置和大小。
- 不再假设所有应用共享完全相同的坐标行为。
如果窗口规则只需要完成“左半屏”“右半屏”“最大化”之类的常见布局，优先使用 KWin 自带的平铺、最大化和快捷键功能，通常比硬编码坐标更稳定。
只有在确实需要像素级固定布局时，才有必要重新计算逻辑坐标。
总结
KDE 在 X11 和 Wayland 下的窗口坐标并不是同一套体系。
X11 下的窗口几何通常接近 X Server 的物理像素坐标，而 Wayland 下的 KWin 主要使用经过缩放后的逻辑坐标。
因此，只要 Wayland 缩放比例不是 100%，X11 下的窗口位置、窗口大小、半屏区域和自动化脚本参数通常都不能直接复用。
显示器的物理分辨率并没有改变，改变的是桌面用于窗口布局的逻辑分辨率。
可以将两者简单概括为：
X11：更接近物理像素坐标
Wayland：使用缩放后的逻辑坐标
这也是为什么迁移到 Wayland 后，许多窗口规则看起来像是“全部失效”。实际上并不是设置凭空损坏，而是底层坐标模型已经改变，旧规则需要按照新的逻辑分辨率重新计算。