jackfiled
e1c5362cf5
All checks were successful
Build blog docker image / Build-Blog-Image (push) Successful in 1m12s
99 lines
7.2 KiB
Markdown
99 lines
7.2 KiB
Markdown
---
|
||
title: 日用Linux挑战 第3篇 放弃Wayland
|
||
tags:
|
||
- 杂谈
|
||
- Linux
|
||
typora-root-url: daily-linux-3
|
||
date: 2023-09-04 14:47:46
|
||
---
|
||
|
||
|
||
成也开源，败也开源。
|
||
|
||
<!--more-->
|
||
|
||
## 放弃 `Wayland`
|
||
|
||
### 转向`labwc`
|
||
|
||
在使用`Hyprland`这个平铺式窗口管理器大概三个月之后，我开始怀疑自己是否真的需要一个平铺式的窗口管理器。
|
||
|
||
作为一个主打“平铺”式管理的桌面管理器，我却很少同时在一块屏幕上显示多个应用，都是将应用全屏之后在显示，再搭配`Meta+1\2\3`切换不同的`workspace`实现不同应用切换的功能。这让我开始思考，也许，我根本不适合使用一个“平铺式”的窗口管理器。其次，我常用的`IDE`——`IDEA`系列让我遇到了一个极为恶性的`bug`：代码重构的弹出式窗口需要很长的一段时间才能显示出来，其时间甚至足够我去喝口水上个厕所。如果我在上班，那么我肯定不会放弃这个显而易见的摸鱼机会，可惜不是。这个`bug`虽然不致命但是过于恶心，毕竟很好的重构思路被打断真的很想先把鼠标扔出去再把电脑砸了。
|
||
|
||
然后我就开始研究工作在`wayland`显示协议之下的堆叠式窗口管理器。首先，我惊喜的发现，目前`Linux`下的两大主流的桌面环境都开始默认使用`wayland`显示协议，~~虽然我并不打算将这两个臃肿的家伙请回来~~。打开我们伟大的`Arch Linux Wiki`，打开`wayland`页面，这里已经贴心的为我们整理好了使用`wayland`显示协议的堆叠式窗口管理器：
|
||
|
||
- `enlightenment`：进入官网一看，对于`wayland`的支持还是“实验性”阶段，pass
|
||
- `hikari`：针对`FreeBSD`开发，pass
|
||
- `KWin`：`KDE`使用的窗口管理器，pass
|
||
- `Liri Shell`：不知为何被我华丽无视，pass
|
||
- `labwc`：看上去还行，一会试试
|
||
- `mutter`：`gnome`使用的窗口管理器，pass
|
||
- `wayfire`：`aur`里面的官方包都不能过编译，这种粪软件还是算了吧
|
||
- `weston`：`wayland`示例合成器总给人一种怪怪的感觉，pass
|
||
- `wio`：官网连接被标记为`dead-link`，pass
|
||
|
||
首先尝试`labwc`，虽然这个软件在`Github`上只有800多颗星，不过作为一个小而精的窗口管理器，这个哥们还是比较完美的适配了我的需求，虽然遇到诸多的小问题：
|
||
|
||
- 没有提供在启动窗口管理器时设置环境变量的方法，导致只能修改`desktop`文件实现这个功能。
|
||
- 设置触控板的自然滚动失败
|
||
|
||
而且作为基于`wlroots`合成器开发的窗口管理器，可以完美继承我在`Hyprland`下的不少设置，像`waybar`、`hyprpaper`等等。
|
||
|
||
### 放弃
|
||
|
||
从今年五月份被`Hyprland`种草，切换到`Wayland`显示协议时算起，我已经使用了三个月的`Wayland`显示协议。刚刚切换到`labwc`使用没超过一周，我就遇到了在`wayland`下的最大缺陷：`matlab`没法正常的使用——虽然软件主界面还可以正常的打开，但是所有的子窗口都没办法打开。恰好那两天我必须要用`matlab`完成一个作业，我直接一波`sudo pacman -S plasma`润回了`KDE`。
|
||
|
||
虽然这个故事听着可能有点突然，但确实就这么发生了，写作这篇博客时使用的桌面环境已经是`KDE`了。
|
||
|
||
下面就简单讲讲这次使用`KDE`的美化思路。这次使用`KDE`几乎完全继承了之前的[美化思路](https://rrricardo.top/blog/2023/01/15/daily-linux-0/)，其中主要的变化为：
|
||
|
||
- 使用`kitty`作为终端模拟器
|
||
- 使用类似于`Windows`下的任务栏显示模式，而不是只显示图标
|
||
- 继承了部分在`Hyprland`下的快捷键
|
||
- `Meta+F`全屏应用
|
||
- `Meta+W`关闭应用
|
||
|
||
|
||
|
||
### Fuck You NVIDIA
|
||
|
||
`matlab`还不是给予最后一击的东西。当我搞到一台使用NVIDIA显卡的笔记本时，真正的噩梦才刚刚开始。首先是驱动，作为一个被`FUCK`的公司，NIVDIA现在在`Linux`上具有三个不同的驱动程序：`nouveau`开源实现的驱动程序，`nvidia`NVIDIA提供的私有驱动程序，`nvidia-open`NVIDIA提供的开源驱动程序，其中`nvidia-open`还在积极的开发阶段，显然是被`FUCK`太多推出的产物。
|
||
|
||
参考`Hyprland`官方文档中对于NVIDIA的支持页面，需要安装`nvidia-open-dkms`包再加上几个内核参数。咔咔咔一顿操作之后，期待的等待电脑重启。`Linux`万年不变的启动信息刷过，然后电脑就黑屏了。
|
||
|
||
作为一个经验丰富的NVIDIA受害者，我轻轻一搜就发现这个由于INTEL的内核驱动和NVIDIA内核驱动冲突导致的问题。然而现在不能进系统，我不得不紧急学习了一波内核启动参数，通过在`grub`中修改启动参数禁用`intel_i915`模块才将系统启动了起来。
|
||
|
||
装好了驱动，现在开始装桌面环境。很遗憾，默认版本的`wlroots`在NVIDIA驱动下兼容性不佳，需要自行修改源代码自行编译，虽然有着万能的`AUR`辅助我们，但是好巧不巧，那段时间正好遇到`Hyprland`项目调整文件结构，使用`AUR`编译失败了。于是我不得不手动`clone`下来修改之后手动编译。
|
||
|
||
历尽千难万险，终于进入了`Hyprland` 的桌面。 本来以为安装完成之后就可以愉快的享（gong）受（zuo）了，没想到是折磨的开始。
|
||
|
||
首先是屏幕闪烁的问题，能明显感觉到屏幕会闪烁，出现的时机是完全随机的。按照`wiki`上的说明，在源代码上打上`patch`之后重新编译安装，没用。文档上还记录了一种“核武器”方式，但是需要修改内核配置和造成功耗提升，不敢试。然后是在`vscode`中遇到“屏幕冻结”的问题。这个问题在频繁上下滚动的时候特别容易出现，具体表现为滚动了但是屏幕上的一部分还是显示滚动之前的内容没有刷新。
|
||
|
||
上述问题正好发生在我发现`matlab`没法在`wayland`下正常工作的时候，一怒之下我就回到了`KDE`。
|
||
|
||
已经是2023年了，`Wayland`仍然是`Linux`桌面环境永远的痛。
|
||
|
||
## 双系统的奇妙bug
|
||
|
||
上文中提到我搞到了一台使用NVIDIA显卡的笔记本，拥有了**强劲**图形性能怎么能不玩游戏呢。但是`Linux`对于游戏支持程序实在是一言难尽，具体可以查看这个系列前几篇我和原神的相爱相杀。于是我就选择了安装`Windows`和`Linux`双系统。
|
||
|
||
由于这台笔记本支持安装多个`m.2`的硬盘位，因此我就将两个系统安装到了两个不同的硬盘中，使用`grub`切换在启动时需要进入哪个系统。
|
||
|
||
### `iwlwifi`加载失败的问题
|
||
|
||
虽然安装的过程一帆风顺，但是使用的过程却是波折连连。出现的第一个问题就是`iwlwifi`这个驱动程序在从`Windows`切换到`Linux`的启动过程中会启动失败。使用`dmesg`可以观察到如下的报错：
|
||
|
||
```
|
||
iwlwifi: probe of xxxx:xx:xx:x failed with error -110
|
||
```
|
||
|
||
一通咕狗容易发现这样的一个[bug](https://bugzilla.kernel.org/show_bug.cgi?id=209641#c55)，似乎是由于`Windows`使用快速启动造成的。
|
||
|
||
解决办法或者说“回避策略”有两个：
|
||
|
||
- 关闭`Windows`的快速启动
|
||
- 遇到这个问题了重启`Linux`
|
||
|
||
于是干掉快速启动。
|
||
|