kuanat

根据 Pop!_OS 加上 nvtop 的提示，我估计是内核版本低了，驱动比较老，没有暴露足够的 sysfs 抽象。780M 是 RDNA3 架构，大概要 6.4 之后的版本才能有比较完整的驱动支持。Pop 是 Ubuntu 22.04 LTS 的衍生版，内核可能还是 5.X ，我不确定官方仓库是不是有足够新的内核。首先要保证内核版本够高，能正确加载 amdgpu 驱动。

如果你说的 chrome 是官方那个 deb 版本，硬件加速是通过 vaapi 实现的，这个版本编译的时候是带了 vaapi 支持和相应解码器的。（某些发行版仓库里 chromium 编译时未开启 vaapi ，像红帽系的发行版 fedora 由于版权问题是缺少一些解码器）

然后为了支持 vaapi ，需要 libva-mesa 驱动。libva 还有个使用 vdpau 后端的驱动，主要是供老一点的型号用的，vdpau 在新架构上基本被 libva-mesa 替代了。

再之后由于 mesa 在 amd 设备上只支持 Xorg/XWayland ，所以要保证 chrome 运行在非 wayland 模式下。如果你没手动指定的话，大概率 session 就是 Xorg 的。

最后就是 chrome 播放视频验证的时候要确认编码格式。说这么多其实我猜测比较可能的原因就是驱动版本和 libva-mesa 。安装好了应该就正常了，还不行你可以再来反馈或者去报 bug 。

续航这个事情，用户能做的事情不太多。不想折腾的话就是买有驱动支持的型号，然后装内核版本尽量高的发行版。


这个事情误区太多，我就多说一些。

首先功耗是动态的，如果拿手机来类比，一般看续航都是所谓的亮屏，然后才是待机。换句话说，高负载一般是用户控制不了的，能优化的其实是低负载的部分。其次如果考虑功耗构成的话，有负载的时候，显示屏可能在 3~5 瓦左右（根据分辨率和亮度会变化），SoC 等等根据平台可能有 15/30/45 瓦这样。低负载的情况下，显示屏还是 3~5 瓦，但是 SoC 可能会降到 1~2 瓦的水平。

所以很容易得到两个结论，工作负载基本只能看耗电大户 SoC 的工艺水平，也就是能耗比，越先进的平台一般越省电。待机功耗已经非常低了，即便把 CPU 降频降压等等，对于全天使用这种混合工况，能够改善的空间也很有限。


那现在硬件厂商、操作系统在不影响用户体验（性能释放）的前提下，还有哪些改善续航的手段？

第一个思路是改变高、低负载工况的比例。这是基于 CPU 的特性功耗范围非常大，短时间高性能快速完成计算任务然后待机，要比长时间中低性能的模式平均功耗更低。以前 CPU 多数运行在甜点频率，然后睿频能够起到平衡性能和功耗的作用，现在越来越出厂灰烬，所以想要长续航还是尽量选为移动平台设计的处理器版本。

第二个思路是没有低负载也要创造低负载，用不到的设备就让它待机。近几年的硬件几乎都支持运行时状态调节，大到 CPU 小到 WiFi 网卡 SSD 硬盘，都可以工作在高性能/节能/待机等模式下，整体都符合 ACPI 规范。如果所有硬件都支持，那么待机功耗能够降低到非常可观的水平。如果硬件平台比较老，或者某些设备只有 Windows 驱动，就会造成无法进入低功耗状态，因而导致续航功耗降不下来。

顺着第二个思路继续延伸，待机的意义其实可以放得更宽。想象一下浏览网页的场景，可能用户只会断续滚动一下以页面，其他时候都是在阅读。这个断续无操作的场景，就是可以激进待机的时机。于是在多方努力下，除了正常工作状态、待机和休眠，又多了一个叫 ModernStandby/s0ix/s2idle （分别是 Windows/Intel/Linux 的叫法）的状态，这个状态功耗接近待机，而唤醒时间非常短。

不过这个特性属于不能用短板那种，一旦某个设备无法进入 idle 状态很可能会把整个系统拉下水。之前 Intel 搞 EVO 认证其实就是这个用意，强制厂家筛选硬件保证这个激进待机能正常运作。

显示屏是这个机制非常好的受益者。高分辨率高刷新率显示屏其实是耗电大户，因为它同时会使 CPU 显示屏工作在有负载状态，还使得二者之间的链路（ pcie/hdmi ）都更加耗电。上述的待机场景，显示内容是不变的，如果显示屏能缓存输出信号自行显示，即可让 CPU 显示屏和链路都进入低功耗状态，这个技术叫 PSR 面板自刷新。配合 s2idle 机制，在长时间使用时可以将平均功耗从 3~5 瓦的水平降低一半。


之所以在上面说软件能做的事情不多，是因为新平台、新技术和新内核的加持下，默认就很好了。我有一台 Intel 11 代的 16 英寸笔记本，型号就不提了，电池容量大概 70Wh 。用 Linux 没做任何设置，满足 8 小时写代码开发工况是很容易的。满电待机（不是 s3 而是 s2idle ）能有 250 小时，也就是说不含显示的功耗能低到 0.3W 左右。

如果真的要折腾一下，Nvidia 独显用户可以考虑 Bumblebee 做个切换。驱动尽量新一点，这样内核可以在 idle 状态下同时让显卡也降低功耗。CPU 调度方面 intel_pstate/amd-pstate 就很好，比绝大多数主动调度要靠谱，可以根据情况手动切换是否开启睿频。至于 TLP 在较新的硬件平台上已经没有什么作用了，针对老硬件不支持运行时电源状态管理的，最好的办法是 udev 规则手动加载卸载。缺乏驱动支持的设备，比如指纹识别什么的也是同理。重点就是关注有没有什么硬件或者 usb 设备影响了系统进入待机状态。

最后说一下 UPower ，它几乎运行在所有发行版上。原本的用途并不是省电，只是恰好有控制硬件中断和延迟的功能。这样即使用户空间的应用程序有不正常的硬件 polling 行为，也不会影响到硬件层面的 idle 和唤醒。（安卓在这个思路上继续延伸，wakelock 增加了对齐机制。）

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 更好的体验，只是需要花费非常大的精力。

PDM 真的很棒，我上次看到作者的回复，想赞美一下 PDM 结果打成 PNPM 了……

对于非专业人士和初学者，我还是会推荐 PDM 的。原因一是基于 Python 生态及现有标准，又比 pip 方便友好，二是成熟项目基本不会踩坑了。


从趋势来看，随着 AI 的兴起，这些年“包管理”这个概念慢慢在向“工程管理”方向转变。生态层面上，就看 uv 能不能统一 Python 工具链了，在这个背景下，独立的包管理工具可能会慢慢淡出视线。

另外 conda 的思路也不一样，我个人认为它更接近于 docker build 这种重建。

就同楼主说的一样，专业人员肯定是要考虑实际需求做选择的。

第一个大概率不是软件问题。建议详细描述一下笔记本型号、硬件配置和连接显示器的方式等等方便大家给出建议。

我印象中 Intel 过渡到真三显支持应该是 11 代之后的事情。在这之前对于三显的支持是内部一个，外部两个共用一个信号源，就是你所说的外接的两个显示器只能复制模式。Nvidia/Amd 独显也有类似的问题，但是原因不一样，主要取决于拓扑结构。

第二个问题，常见的登录界面（ gdm/sddm ）的软件逻辑是一个特殊账号的桌面，这个账号有自己的显示器配置。一般你把自己账号里面的显示器配置文件复制到这个特殊账号里面覆盖掉就好了。