如何评价一个新的基于 Wayland 的 Linux 桌面环境： Hyprland?

[wwwuser]

一个新的基于 Wayland 的 Linux 桌面环境：Hyprland ， 看官网的介绍，看起来还不错，和 i3 有得一拼哦,有使用的大神吗，可以来说说

https://hyprland.org

[ityspace]

@cnbatch Hyprland 可以配置多屏显示。
monitor=name,resolution,position,scale
比如让两块屏幕显示同一个桌面。
monitor=DP-1, 1920x1080, 0x0, 1
monitor=DP-2, 1920x1080, 1920x0, 1

[ityspace]

@knva 我在 M 芯片的 Macbook 上用的。起码 Aarch64 上能用。

[tedzhou1221]

manjaro + hyprland 用了一个星期。 同一个应用，有多个界面，不知道如果才能方便切换。

[Jirajine]

@cnbatch #19 多个屏幕不同 dpi 的场景，和 DE/WM 基本没啥关系，wayland 下都可以为不同屏幕设置不同缩放。
问题在与应用本身，你启动一个应用，应用得自己探测当前屏幕的缩放比例;你把它的窗口移动到其他屏幕，它得自己响应这个事件绘制新的缩放比例的像素。这一点连 windows 也不是每个应用都支持的。

[klesh]

@Jirajine 说得对。现在的问题不在于 wm de 和 wayland ，而是 apps 的支持不行。

[klesh]

@ghjh 是分数缩放。163 dpi 用 2 倍太大了些。😂

[kuanat]

TLDR: Hyprland 总体来说很不错，日常可用稳定性也可以，开箱即用的水平中游偏上，比不上 KDE/Gnome ，但好于其他同类 wm 。

目前 Wayland compositor 的实现主要有三个：Mutter(Gnome)/Kwin(KDE)/wlroots(sway)，前两个与 DE 绑定，其他桌面实现包括 Hyprland 都是基于 wlroots 的。区别重点有两方面，一是对于协议的支持，协议指的是各种功能规范，比如输入法、锁屏等等，另一方面是渲染后端支持。

渲染后端指的是 framebuffer 的抽象，Intel/AMD 显卡用的是 GBM ，而 Nvidia 用的是 EGLStreams 。Kwin 已经官宣放弃支持 EGLStreams ，Mutter 支持比较好，而 wlroots 从一开始就不支持（有 fork ）。Nvidia 的闭源驱动从 495.44 之后提供了 GBM 的实现，所以新一点的显卡，是可以正常跑 Wayland 的，但是有不少兼容性问题，或者用开源驱动，但就是功能和性能不太行。

窗口合成器一般分 stacking/tiling/scrolling 几类，帖子主题是 Hyprland 那就只聊 tiling 类型的。现在基于 wlroots 的主流实现就是 Sway/Hyprland/dwm/river 几个。基于 wlroots 也有可能是基于某个版本的 fork 实现，所以支持的渲染后端和协议也不同，比如 Hyprland 就早于 Sway 支持 input_method_v2 ，但由于 Hyprland 通过 GLES 做的特效，所以尽管上游 wlroots 已经支持 vulkan 但 Hyprland 就无法支持。

dwm/river 我没怎么用过，就不评价了。如果要在 Hyprland/Sway 里面选，除了上面说的 vulkan 支持，就看你的使用习惯是手动还是自动布局。Sway 是纯手动的，Hyprland 支持 MasterStack 模式的自动布局。Sway 开放了 IPC 实际是可以很简单实现自动布局的，不仅可以用 Python 之类的脚本来写，也有其他语言的 binding 。Sway 自由度更大，加上是 wlroots 的官方开发，所以稳定性好很多。



PS 随便多说点，给想尝试 Sway/Hyprland 的做个参考。

由于 Sway/Hyprland 只是个 WM ，所以真要日常使用需要额外配置很多东西，这里列举几个影响使用体验的因素。

第一个就是常说的分数缩放，然后又要分 Wayland 原生应用和 XWayland 应用。（后者只有 KDE 做了额外的支持，其他几家不做的原因主要是理念，wlroots 这边的意思是，不该我管的事情我不管。） XWayland 应用一定会模糊，但是这个影响已经很小了，现在 Chrome 系和 Electron 都已经有了原生实现，可以通过命令行参数切换到原生模式。

相关的协议 wp-fractional-scale-v1 大概是去年合并的，在此之前的渲染逻辑是 200% 渲染之后 downsample 。新协议变成了客户端（应用程序）可以获知缩放参数，然后自己完成界面逻辑。只是这个新协议要 GTK4/QT6 的支持，不过在不支持新协议的应用上（ GTK3/QT5 ）还是会回到之前的模式上。无论哪种模式都不会模糊，只是新协议不需要 200% 渲染这种低效的操作了。

第二个多屏幕支持，我个人认为非常好了，不同显示设备可以支持不同 DPI 。由于 tiling 模式是不存在某个状态一个窗口横跨两个显示设备，所以处理起来简单很多。

这里 Sway 有个优于 Hyprland 的功能叫 multiseat ，可以按照 seat 为输入输出设备进行分组，每个 seat 有独立的输入焦点。这个功能对于多输入设备（触摸板/鼠标/触摸屏）和多屏非常有意义，比如多焦点的情况下，可以在副屏上触摸操作，而不影响主屏。

第三个是中文用户关心的输入法。由于 wayland 输入法相关的协议众多，基本不建议用 fcitx5 之外的任何输入法框架，因为 fcitx5 已经实现了所有能支持的一切。Sway 1.9 也合并了 input_method_v2 ，所以和 Hyprland 没区别了。应用程序侧 input_method_v2 主要是影响某些终端 vte 显示候选框的问题，chrome 系支持了 wayland-ime 和 gtk4 也可正常使用了。

第四个是状态栏，主要的实现是 waybar/yambar/eww 几个。最大的麻烦是 tray 支持，即在状态栏显示客户端应用自定义的图标，并支持交互功能，毕竟不是 Gnome/KDE 不会有应用专门去做相关支持的。waybar 稍微好一丢丢，因为它本身是个 gtk 应用，eww 算是套壳，yambar 需要自己想办法。

小问题是状态栏的工作逻辑，我看到的除了 yambar 大部分功能实现都是基于 polling 做状态轮训，这其实是个比较低效的做法，比如显示笔记本当前电池电量，正确做法其实是通过 udev 规则触发显示更新。再比如不使用 tray 的情况下，要显示输入法状态轮训就不合适，因为这个状态切换需要接近实时，然后绝大部分时间状态是不变的。合理做法是用 fcitx5 lua 功能监听状态变化事件，然后主动触发显示更新。

第五个是锁屏。之所以说这个是因为锁屏可选的实现很少，目前一定要正确实现 ext-session-lock-v1 才可以。原本 Linux 图形界面的通常逻辑是在 tty 之上的，比如 Gnome 登录界面（ gdm ）一般在 tty1 上，登录验证完成后，在 tty2 上开一个当前 session 的界面，锁定后又会回到 tty1 上。目前应该是只有 Gnome 把锁屏做到了 wm 上，其他都是用一个单独的程序当作锁屏。这就是前面那个协议的意义，这个锁屏程序如果 crash 掉了，正确实现协议可以保证不会意外解锁。

第六个是截图录屏，放到前两年这还算个事，调用 wayland 实现的截图录屏软件就都没什么问题。有问题的是类似 XX 会议这种，如果自身是 XWayland 实现，就没法共享桌面，有极其复杂的曲线救国的方式但是不推荐。如果是基于浏览器或者 electron 的实现，就可以正常录屏，因为相关调用走的是 wayland 协议。

剩下的放到一起说，主要是 systemd 集成和各种权限问题。我估计应该没有人刻意不在桌面环境用 systemd ，大部分人都会主流 DE 选一个然后再另外安装 Sway/Hyprland ，少部分 Arch/Gentoo 用户会直接上。systemd 能简化很多事情，但不熟悉的话很多细节问题就难以解决。

举个例子来说，因为不是 DE 而是 WM ，就连调节屏幕亮度这样的功能也要自己写脚本实现。但是调节亮度需要操作对应设备 sysfs 文件，那就有几个思路：要么给当前用户 sudo 命令免密码的授权，要么 udev 规则给当前用户显示设备权限，要么写个程序赋予 SUID ，或者是调用 systemd-logind DBus 接口。从安全的角度来看，当然是最后一个方法最合理，但是绝大多数人应该都不了解。

再比如 systemd-logind 默认对于电源按键的响应是关机，希望调整为待机，如果是 Gnome 这种，可以在系统设置里去调整。按照一般思路，用户会去修改 logind 的配置。但按照 systemd 的设计和各个主流 DE 的实现，符合逻辑的做法是通过 systemd-inhibit 获取 handle-power-key 的锁，这样 systemd 会忽略对 XF86PowerOff 按键的响应，之后 WM 可以自行绑定相关按键来执行想要的功能。

如果是从其他 DE 迁移过来，之前依赖特定桌面的功能，比如 keyring 什么的，就需要调用对应的 polkit agent 来获取授权。其实 DE 做的有关用户体验的事情非常非常多，想要全都迁移到 WM 层面就需要非常多的工作。我再举个例子，Gnome/gdm 的登录是可以支持同时对密码和指纹进行验证的，这里同时的意思是按输入键就验证密码，直接刷指纹也可以。我原本以为这是个很简单的配置问题，研究之后才发现，密码和指纹校验本身确实都是 PAM 机制来做，但仅仅依靠 PAM 机制是做不到同时检测的。PAM 的设计就是线性序列化的，要么先指纹，失败了再验证密码，要么反过来。想要做类似的功能就要写一个并行验证的逻辑，然后这个模块又必须正确实现锁屏协议，还要负责处理 session 相关的管理，这就不是个人用户能手搓的了。

做个简单总结，如果你对系统足够了解，开发能力足够强，Sway/Hyprland 这种 WM 经过自定义能获得比 Gnome/KDE 更好的体验，只是需要花费非常大的精力。

[wolfan]

最新装逼神器。

其实换个思路，hyprland 可以很好的改造成 FUI ，在影视制作的时候使用。

[Greendays]

官网有二次元，好评！

[FYFX]

双屏不同 dpi ，可以设置不同缩放，我跑 xwayland 有问题，纯 waylnad 应用起来好像没啥问题 @cnbatch

[wwwuser]

@xclrr
@klesh 看来是目前的真知灼见了，那等稳定成熟了再折腾了吧

[wwwuser]

@ityspace 干掉了 MacOS 吗

[wwwuser]

@kuanat 资深玩家，科普的也是挺深刻的

[jqtmviyu]

应该不选新了, 要稳定就不能用 Wayland, 用回 x11.
喜欢平铺有 bspwm, i3 等可以选.

但 Hyperland 的动画真的是丝滑.

[dandycheung]

@kuanat 这样质量的回复，值得再手动赞一次。

[lxcForPHP]

@klesh 是的，确实自己没有设置好，好多不知道从那里下手去排查，刚从把 chrome 浏览器的问题解决了，一下子感觉顺眼多了

[ryan4yin]

Hyprland + Nvidia 已经使用一年有余，主要是 Nvidia 的坑比较多，不过踩完坑后体验还是挺好的，尤其是 Nvidia 今年的新驱动修了一堆 wayland 的 bugs 之后。
个人感觉 Hyprland 相比 Sway 最大的特点是自带动画效果以及自动的窗口布局，喜欢 WM 以及过渡动画的可以尝试下。

[ryan4yin]

Hyprland 算是近两年 WM 圈子里的网红了，各种 Ricing 的出境率很高。

[WispZhan]

既然这样，那我推荐一个项目，最近我也打算试试。
https://gitlab.com/stephan-raabe/hyprland-starter

[Kaiv2]

@knva arm 能用，mac air m1 使用正常