Allen Hua 的网络博客
type: channel
link: https://hellodk.cn/
description: Allen Hua 的网络笔记
items: 绝壁与深谷：2026盛夏的南太行自驾游
items: 海风与旧巷：2026盛夏的深港澳行记
items: 机械革命泰钽 plus linux Debian Wayland 独显直连调优全记录
items: MECHREVO WUJIE14 PRO on Linux 声卡完整修复历程
items: 记录一下我删除相机 SD 卡当中废片的工作流
items: Linux Desktop 使用 NVIDIA 独显驱动 Google Earth Pro 和 WeChat
items: 实现了一套Linux下快速查词/翻译句子的工作流-linux-quick-translate
items: 开发了一个基于和风天气 API 的 Android 天气应用
items: 由于 Linux 桌面没有一个好用的天气程序就写了一个跨平台的CheckitoutWeather
items: 给 caesium-image-compressor 图片压缩程序构建了 Linux AppImage v2.8.5 最新版

绝壁与深谷：2026盛夏的南太行自驾游
type: item
date: 2026-08-11T00:17:00+08:00
description: 前言 从合肥休息好之后我回到了南京，决定接下来去哪里。因为时间不充足了，所以放弃了川藏线，尽管我还真的没有去过西藏，只走过川西小环线，那就以后再达成这个心愿吧。台风“红霞”刚走不久，“白海豚”又准备在浙江沿海登陆，所以也放弃了沿海自驾。最终确定南太行，这里也是一直魂牵梦绕我的地方。这一段旅程很紧凑，短短四天。 day 1 南京出发，前往河南省新乡市辉县市。整理好行李，去了一趟好想来买一些泡面香肠卤蛋什么的，开上我的斯柯达明锐，冲呀。上午快要11点才真正出发，但因为开的挺快挺顺畅，晚上7点就到了酒店。 下楼吃了一顿辉县特有的麻辣烫，但端上来时我询问是不是你们这边的特色“酸甜口味的麻辣烫”，老板说，“不是，很多人不习惯吃这种口味的，只有你们明确讲了需要酸甜口味才会给你们做那种” 那还有啥办法呢，好可惜，吃不到特色就算了吧，以后还有机会的。 当我做细致的路线攻略时发现天塌了，最近雨季，南太行这边有些地方山体滑坡、落石，导致武家湾和黑毛沟大峡谷封路了。然后我加了一个抖音自驾群获取了最新消息，群主分享了最保险且风景不差的路线，于是我就主要参考了这条线进行第二天的旅程。路线大致是： 宝上路-棋子山-浙水村-东柏坡天路-神龙湾挂壁观景台-井底村-高家台-鲁班天梯-石板岩小镇 美美睡觉，期待明天路上的美景。 day 2 早上7点多出发，加满油前往四十多公里之外的「崖边咖啡」，也就是「宝上路观景台」，或者「赶羊站观景台」。就是今天天气不给力，有很大的雾，暂时散不开，可惜在国家地理杂志封面图拍摄打卡点拍不到很极致的照片了。 到了崖边咖啡，要尽快找空位停车，今天是非工作日并且我来得早可能还好，大家以后想去一定要记得优先停车，多走几步路再看风景都是小事，因为越到后面停车越耽误时间才是大事。国内现在只要稍微人多的地方都是这样的，太多人出来游了，停车老大难。 空气不那么通透，因为雾气弥漫，所以先拉一下长焦拍个特写看看。 初次看到这个崖壁还是很震撼的，左侧崖壁之上就是公路，刚才就从那个方向驶来。很多崖壁像是刀切豆腐一样。 国家地理杂志封面图同款/相似机位，来这就是为了这张照片 2333。 下面应该是5A级景区宝泉旅游区的景区公路。只能景交车才能行驶🙃 我向前走了一段路，看到下面的宝泉旅游区，感慨这个观景位置也很不错啊，还是免费的，除了天气不通透，在这里吹一会山风也觉得来值了。 不知道为啥还是有很多车行驶到武家湾那边，也许还有别的小路或者他们就到途中再折返吧。反正我下山了，驶向了焦作云台山那边，然后走G207国道和乌海线到棋子山，就是网红猪八戒打卡点那里。这段路一直爬坡，还有个让我喜出望外的“叠彩洞”，我原本的攻略并没有这里，自驾群里的攻略也是建议走沿太行高速-郑辉高速-陵侯高速到棋子山，但是最终我选择了走国道，因为风景不在高速上（在的话也没办法停车欣赏和拍照）。这里让我哇哇叫，也太帅了：20条隧道，好几个隧道里都有U型弯，简直太刺激了。不过隧道里有一辆车轮子掉沟里了，大家注意安全驾驶。下图是进隧道之前拍摄的 上到山顶差不多来到了“一斗水村”，我找了荫凉处停车，拿出零食开炫，先垫吧垫吧。山顶处格外凉爽，这瓶AD钙奶都显得格外好喝。 后面继续赶路到棋子山，沿途遇到好看的风景我都尽量停车欣赏，当然停车不能影响别人，也不能给别人带来危险。下面几张这种高山小村落非常的宁静祥和，让人心情愉悦，晚上住在这里应该都不用空调还要盖被子吧。（PS：这里就是山西晋城市陵川县，一个可能不那么知名的避暑圣地） 到了棋子山这边，海拔1500多，山顶是真的凉爽，还有人铺上席子在打牌，好不惬意。 遇到一个大哥，找我搭话，后来和我讨论晚上住哪里，他说前面很多村子都有民宿，但我还坚持回县城住酒店。查了一下距离也才20多公里。 为什么回县城住酒店： 因为县城文明 服务和价格透明 还有更多的美食以及文化可以探索 我出去旅游不是很喜欢住民宿，民宿条件以及老板水平参差不平的。县城是我最爱的落脚点，地级市的市区可能千篇一律，并且价格稍高，但是县城很折中，很有性价比。 速度买好了县城中心的酒店，火速赶往，一路上非常快乐，下山的风景太好了。另外就是要提一下，陵川县城可能因为很多人前来避暑，尤其大批的河南人，加上陵川是晋城市唯一没有开发煤矿的县城，所以他们高度依赖旅游业，于是住宿相比周边其他县城以及物价水平都要稍微高一点。 今天时间还比较早，我在酒店收拾好洗了澡出来逛小县城，发现这个小县城的婚嫁门店还挺多。之前在陕西榆林，那边的街头很多洗脚店。哈哈，还真就反映了当地人民的生活吧。这也是旅行有意思的地方，能感受到不同地方不同人们的生活方式和文化差异。用随身的红米K70 拍了下面8张照片，都有比较大的压缩，方便快速加载。我觉得挺富有生活气息的，回味起来，总感慨同一片土地上，不同时空角落，就上演着截然不同的人间烟…

海风与旧巷：2026盛夏的深港澳行记
type: item
date: 2026-08-10T21:34:00+08:00
description: 终于又到了属于我的假期，今年的假期有两个星期，我可要好好安排一下。准备分成两段，第一周去深圳香港澳门，第二周暂时没想好，但是决定了是自驾，皖南很多地方都转过了，所以有几个选项 川藏线 南太行 浙江海岸线，比如仓南168黄金海岸线，中国东海岸1号公路 先写我的深圳香港澳门游记吧，具体的第二周安排我是在出发前一天才真正做好决定的。 day 1 今天的飞机飞深圳，因为台风“红霞”，延误了一个多小时，好在10点多正常降落深圳宝安机场，但是到达我哥那已经晚上12点了。这个台风稍微打乱了我的游览节奏。 day 2 第二天，深圳福田一直在下雨，直到下午天气才稍稍明朗些，但仍然会滴落一些雨滴。不过我在房间待不住，去了深圳湾人才公园打卡，并且拍了一些照片。 这两天深圳比较凉快，反而是南京顶着骄阳，还有35度高温，稍稍成功的一次避暑。找了辆共享单车，沿着深圳湾滨海大道骑了 4 5 公里。海湾区除了湿度太高，其他的条件还是蛮舒适的，因为风多，气温也不是很高。晚上和我哥吃了当地特色“隆江猪脚饭”，还是非常不错滴。 此时台风红霞的中心已经北上，但是深圳仍受其外围云系笼罩，饱含水汽的云团漫过楼宇，层云垂落，缭绕于城市高楼之间，看着颇有意境。 云层太厚，可惜今晚没有晚霞了。不然这个打卡点是个拍摄晚霞、夕阳🌇的好地方。 day 3 今天计划徒步海岸线，看过大海却没有进入过沙滩，刚好去大梅沙，小梅沙走走沙滩。从深铁盐田墟下车，沿着海岸步道（其实叫“盐梅路”）总体是向着东北徒步。今天有一些阳光，还是有些晒人的。 大梅沙，深圳东部大鹏湾的海湾。数百年前这里只是一处偏僻的客家小渔村，世代村民靠出海捕鱼、耕海为生，山海闭塞，与世隔绝深圳盐田。 谁曾想，乘着时代浪潮，昔日的渔家村落，蜕变为如今繁华发达的滨海小镇。月牙形的沙滩、林立的酒店楼宇，山海与城市在此相融。 第一次触到海滩的细沙，细碎的颗粒绵软顺滑，从指缝间悄悄滑落。它们本是山石的碎屑，经海浪千万次拍打打磨，才化为这般细腻模样。潮起潮落，造物的循环仿佛在此触手可及。 今天是工作日，但是海滩上仍然有很多人玩水，如果是炎热的工作日，这里就真的是下饺子。这边的海水挺干净的，确实很适合玩水，不在滨海城市生活的我有些羡慕。 day 4 HK是真的蛮出片的，但是限于篇幅，只挑选了最喜欢的一些分享给大家。今天一大早8点多就到了香港，但是没料到下了大雨，台风的影响仍未结束，这种天气也见怪不怪的。好在下午放晴~ 我最喜欢太平山了，在香港市区生活，处处显得逼仄，街道、居室都局促狭小，高楼挤得很近，但因为香港有很多山，让我觉得又很相得益彰。虽然那些空间不属于你，但大部分也都是公共的，有山有海还有盘山公路，感觉累了就可以跑山，开车到山顶吹吹风，很喜欢这种感觉了。 另外也赞美一下太平山顶看中环以及对面维多利亚港那片的夜景，真的很赞。 晚上回深已经22点多了，都没赶上福田口岸，最终在罗湖口岸抵深。 day 5 又是下雨的一天，加上昨天3万多步走累了，就不想再去香港了，本来还打算续一下签注再去趟香港。 下午去打卡深圳华强北，这个对于我这种数码迷还是挺有吸引力的。打算买个华强北悦虎耳机，高仿 AirPods Pro的，但是搜了一下水太深：又是悦虎，又是洛达，还有杰里、中科蓝汛，还有FlyCC软件验证，各种名词（有主板方案，有芯片名称），这些倒不会出现在展台。但是展台上只有五代、六代、七代、八代，真七代这些模糊的词语，让人眼花缭乱的，不如京东自营买大厂成品 tws 耳机。看了好几家，也试用了一下，感觉还是不错的，就是需求不大，最后就没买。再记录几个有意思的点： 我看有家卖共田的风扇，我说这个图案（logo）明明就是共田，他们居然说不是，倒是没说清楚具体是什么牌子 看到有人手搓电池，是软包的，我发挥e人属性，问他我可以拍一下吗，他表情严肃的拒绝了 😂 我居然买了一个触控笔，哈哈，老板说10元，被我还价到了7元。一头是塑胶的，另一头是导电布那种的，质感挺不错的，来华强北最大收获！（将在下文配图） day 6 我一个人的澳门一日游。一大早7点多乘上了前往珠海拱北口岸的大巴，现在涨价了要49.9，看小红书之前只要19.8，也是最近一年才涨价的，遇到节假日可能还更贵。 澳门老街眼见之处，也总是斑驳陈旧，墙皮剥落，街巷狭小。可一经镜头定格，褪色的墙面、复古的招牌，便沉淀出满满的肌理与故事，世俗的旧貌，化作浓郁的复古氛围感，也很出片。 澳门街头的日本元素相比香港也更多，丰田本田日产的车子，还有三菱，铃木等国内现在很少见的品牌。摩托车也有非常多的 Honda，便利店、居酒屋、唐吉诃德、药妆、动漫 IP，很浓厚的日本氛围。 在美狮美高梅看到了坤坤的演唱会海报，是真的很有风格嘞。 中午都没有吃饭，因为在大三巴一路试吃，还有澳门美高梅和美狮美高梅免费的小食饮品几乎都吃饱…

机械革命泰钽 plus linux Debian Wayland 独显直连调优全记录
type: item
date: 2026-06-24T10:21:00+08:00
description: 机械革命泰钽 Plus 游戏本在 Linux Debian GNOME Wayland 下流畅使用诊断艰辛历程 一、软硬件配置 硬件 项目 规格 型号 MECHREVO Taitan Series GM7TG0M CPU 11th Gen Intel Core i7-11800H × 16 (8C/16T, Tiger Lake-H) 独显 NVIDIA GeForce RTX 3060 Laptop GPU (6GB GDDR6) 核显 Intel UHD Graphics (Tiger Lake-H GT1, 集成于 i7-11800H) 内存 64 GiB DDR4 磁盘 1 CT240BX500SSD1 240GB SATA SSD 磁盘 2 Fanxiang S500PRO 1TB NVMe SSD 磁盘 3 IM2P33F8-512GD 512GB NVMe SSD 固件 N.1.07MRO06 BIOS 显卡模式 dGPU Only (独显直连) / MSHybrid (双显卡混合输出) 软件 项目 版本 操作系统 Debian GNU/Linux 13 (trixie) 架构 x86_64 桌面环境 GNOME 48.7 窗口系统 Wayland 内核 Linux 6.12.90+deb13.1-amd64 NVIDIA 驱动 595.80 (私有驱动) NVIDIA VA-API nvidia-vaapi-driver 0.0.13 (NVDEC 后端) PipeWire 1.4.2 腾讯会议 v3.26.10.401 (deb 包安装于 /opt/wemeet) 二、双显卡 vs 独显直连：两难抉择 2.1 混合输出模式 (MSHybrid) 的问题 BIOS 中设为双显卡混合输出时，系统主 GPU 是 Intel 核显，桌面合成器（Mutter）由核显驱动。但笔者的两台外接显示器（一台 4K 27 寸、一台 1080P 24 寸）通过 HDMI 和 USB-C 直连到了 RTX 3060 独显，这意味着：外接屏幕的最终画面输出必须经过 NVIDIA 独显。每一帧渲染流程为 Intel 核显合成→经 PCIe 总线拷贝到 NVIDIA 显存→NVIDIA 输出到屏幕，这个跨 GPU 的 PRIME 缓冲区同步过程引入了显著的延迟和掉帧；同时 Mutter 同时管理两个 GPU 的 framebuffer，帧时序难以对齐，进一步加剧了卡顿感。 为什么 Windows 没这个问题？ Windows 下 NVIDIA Optimus 的混合输出走的是一个更高效的路径：NVIDIA 驱动内置硬件拷贝引擎（cross-adapter copy engine），独显渲染的画面通过 PCIe 直接写进核显的 framebuffer 然后输出到屏幕，不需要等待双向同步和帧对齐。而 Linux 的 PRIME 方案目前依赖通用 DMA-BUF 机制进行跨 GPU 缓冲区共享，多了一层软件调度开销，在 4K 高分辨率下带宽压力更大，卡顿感就非常明显。本质上不是硬件不行，是 Linux 图形栈在双 GPU 调度上还没做到 Windows 的成熟度。NVIDIA 在 Windows 下的图形驱动已经打磨了超过 25 年（自 1999 年 GeForce 256 发布算起），Optimus 双显卡切换技术也已在 Windows 上迭代了 15 年以上；而 Linux 下的 PRIME 多 GPU 同步方案直到 2016 年前后才逐渐可用，Wayland 下的双 GPU 混合渲染就更加年轻。十几年的工程积累差距，不是短期内能抹平的。 Waydroid 正常 — Android 容器通过 Mesa 调用 Intel iGPU 做 GPU 加速 腾讯会议各项功能正常 — 屏幕共享打 patch 后也能正常创建分享，别人能看到 桌面流畅度不佳 — GNOME 动画卡顿，窗口拖拽/切换时有可感知的延迟 补充：混合模式下若改用 X11 显示协议，流畅度问题同样可以得到缓解——X11 的 GPU 调度路径更成熟，PRIME 同步开销较低。但笔者不选择此方案，因为 Wayland 是 Linux 桌面显示的明确未来方向，且大部分日常软件（包括通过 XWayland 兼容层运行的）在 Wayland 下已足够稳定。放弃 Wayland 换 X11 是走回头路。 2.2 为什么不能只用 Intel 核显 (iGPU Only) 最理想的情况似乎是 BIOS 设为 iGPU Only，只用 Intel 核显驱动内置屏幕，简单省电。但这是不可能的，原因在于本游戏本的硬件设计： HDMI 和 USB-C（DP Alt Mode）视频输出接口在物理上直连到了 …

MECHREVO WUJIE14 PRO on Linux 声卡完整修复历程
type: item
date: 2026-06-18T16:46:00+08:00
description: 为了解决我的机械革命无界 14 pro 笔记本在 linux debian testing(forky) 下的自带麦克风、自带扬声器、插入 3.5mm 耳机这三个场景下，对应硬件都能正常工作的问题，遂有了此文。 前景提要：机械革命无界14Pro笔记本debian forky成功驱动内置扬声器和麦克风 系统信息 项目 值 机型 MECHREVO WUJIE14 PRO CPU 12th Gen Intel Core i7-12650H 声卡 Intel Alder Lake PCH-P HD Audio (8086:51c8) Codec Realtek ALC256 (10ec:0256) 子系统 ID 1d05:170b 固件 SOF (Sound Open Firmware) 签名固件 2025.05.1 OS Debian forky/sid, GNOME 50, Wayland 内核 7.0.10+deb14-amd64 PipeWire 1.6.6 + WirePlumber 1.6.6 ALSA UCM2 alsa-ucm-conf 1.2.15.3-1 目标 确保以下三个场景全部正常工作： 场景 状态 内置数字麦克风（DMIC） 始终正常 内置扬声器 始终正常 3.5mm 耳机插入后 修复前无声，修复后正常 问题 插入 3.5mm 耳机后声音仍然从笔记本内置扬声器输出，耳机无声音。系统设置输入设备显示正常（内置数字麦克风可用）。 根因分析 三重故障叠加 ┌─────────────────────────────────────────────────────────┐ │ 问题 1：硬件插孔检测不工作 │ │ ALSA 控制 "Headphone Jack" 始终 = off │ │ 即使耳机物理插入，Codec (Node 0x21) 的 pin sense 未触发 │ │ 可能原因：SOF 驱动与 ALC256 pin sense 事件处理有兼容问题 │ ├─────────────────────────────────────────────────────────┤ │ 问题 2：UCM2 启动时禁用 Auto-Mute │ │ /usr/share/alsa/ucm2/HDA/init.conf │ │ → cset "name='Auto-Mute Mode' off" │ │ 设计意图：让 PipeWire 用户态管理切换，但 UCM2 配置有缺陷 │ ├─────────────────────────────────────────────────────────┤ │ 问题 3：Speaker 和 Headphones 在不同 HiFi Profile 中 │ │ 两者共用 PlaybackPCM "hw:0"，ACP 拆分成了两个互斥 Profile │ │ Headphones 依赖 JackControl，端口永远 "not available" │ │ 导致 PipeWire 无法激活耳机 DSP 通路 │ └─────────────────────────────────────────────────────────┘ 为什么 model= 参数无效 本机使用 SOF/avs 驱动栈（snd_soc_skl_hda_dsp），声卡名 sof-hda-dsp snd-hda-intel 模块虽然被加载，但依赖计数为 0，不参与实际驱动 /etc/modprobe.d/alsa-alc256.conf 中配置的 options snd-hda-intel model=xxx 在 SOF 下不生效 修复后该文件应当为空（或直接删除），避免误导 强制使用传统 HDA（snd-intel-dspcfg.dsp_driver=1）会丢失内置 DMIC 音频拓扑（ALC256 Codec 节点路由） ┌──────────┐ hw:0 PCM ──────┤ DAC 0x02 │──┬── Pin 0x14 (Speaker) ── 扬声器 │ (Speaker)│ │ └──────────┘ │ ├── Pin 0x1b (unused) └── Pin 0x21 (HP β) ── 耳机(辅) ┌──────────┐ hw:0 PCM ──────┤ DAC 0x03 │───── Pin 0x21* (HP α) ── 耳机(主) │(Headphone)│ └──────────┘ * 表示活动连接 关键：两个 DAC 接收同一路 PCM 音频流，SOF DSP 固件根据激活的 Profile 控制哪个 DAC 通路工作。 修复历程（失败记录） 尝试 方法 结果 原因 1 mo…

记录一下我删除相机 SD 卡当中废片的工作流
type: item
date: 2026-06-14T10:05:00+08:00
description: 采用 python 脚本实现（python3）。支持图片（JPG/ARW/HEIF 等）和视频（MP4 + 配套 XML 元数据）的筛选删除。 相关说明： Linux/mac 电脑，如果你是 windows 电脑那么脚本需要稍加改造 相机当中开启了拍摄的照片按照日期文件夹存储，这种功能，否则可能一个文件夹下的照片数量特别多，你需要维护一个特别长的 keep.txt keep.txt 当中的文件名可以是完整文件名，也可以不包含扩展名。 a. 如果是完整文件名，那脚本就根据完整文件名匹配去保留/删除文件 b. 如果只包含文件名 stem，没有扩展名，将匹配所有包含 stem 的文件名，进而执行保留/删除逻辑。比如 keep.txt 当中有这样一行 HDK09432 ，那这些文件 HDK09432.JPG, HDK09432.ARW, HDK09432.HEIF 都会被保留，这尤其适用于你开启了 JPEG/RAW 拍摄，那么一张图片会有两个文件 支持模拟运行，只需要在最后添加 --dry-run 支持的扩展名：.jpg .jpeg .png .arw .heic .heif .hif .dng .mp4 .xml 索尼视频的 XML 元数据文件会自动匹配对应的 MP4 主文件（如 C0054M01.XML 跟随 C0054.MP4 同进退），无需在 keep.txt 中单独列出 照片工作流 索尼 JPEG 照片扩展名是 JPG，RAW 拍摄文件扩展名是 ARW，HEIF 拍摄扩展名是 HIF (Apple 的 HEIF 照片扩展名是 HEIC) cd /run/media/dk/708D-3AF3/DCIM/15660613/ ls HDK09429.JPG HDK09432.JPG HDK09435.JPG HDK09438.JPG HDK09441.JPG HDK09444.JPG HDK09447.JPG HDK09430.JPG HDK09433.JPG HDK09436.JPG HDK09439.JPG HDK09442.JPG HDK09445.JPG HDK09448.JPG HDK09431.JPG HDK09434.JPG HDK09437.JPG HDK09440.JPG HDK09443.JPG HDK09446.JPG HDK09449.JPG $python3 ~/Downloads/myapps/delete_unwanted_media.py ./keep.txt --dry-run ========== 执行模式 ========== DRY RUN [DRY-RUN] 将删除: /run/media/dk/708D-3AF3/DCIM/15660613/HDK09429.JPG [DRY-RUN] 将删除: /run/media/dk/708D-3AF3/DCIM/15660613/HDK09430.JPG [DRY-RUN] 将删除: /run/media/dk/708D-3AF3/DCIM/15660613/HDK09431.JPG [DRY-RUN] 将删除: /run/media/dk/708D-3AF3/DCIM/15660613/HDK09433.JPG [DRY-RUN] 将删除: /run/media/dk/708D-3AF3/DCIM/15660613/HDK09434.JPG [DRY-RUN] 将删除: /run/media/dk/708D-3AF3/DCIM/15660613/HDK09435.JPG [DRY-RUN] 将删除: /run/media/dk/708D-3AF3/DCIM/15660613/HDK09436.JPG [DRY-RUN] 将删除: /run/media/dk/708D-3AF3/DCIM/15660613/HDK09437.JPG [DRY-RUN] 将删除: /run/media/dk/708D-3AF3/DCIM/15660613/HDK09439.JPG [DRY-RUN] 将删除: /run/media/dk/708D-3AF3/DCIM/15660613/HDK09443.JPG [DRY-RUN] 将删除: /run/media/dk/708D-3AF3/DCIM/15660613/HDK09444.JPG [DRY-RUN] 将删除: /run/media/dk/708D-3AF3/DCIM/15660613/HDK09445.JPG [DRY-RUN] 将删除: /run/media/dk/708D-3AF3/DCIM/15660613/HDK09446.JPG [DRY-RUN] 将删除: /run/media/dk/708D-…

Linux Desktop 使用 NVIDIA 独显驱动 Google Earth Pro 和 WeChat
type: item
date: 2026-06-12T16:09:00+08:00
description: 更新说明 2026年6月17日 09:00 gnome 桌面自带这样的功能，右键就能“使用独立显卡启动”，看下图 原理 NVIDIA 官方提供了 PRIME Render Offload 机制，通过环境变量让指定程序走独显渲染： __NV_PRIME_RENDER_OFFLOAD=1 — 告诉 NVIDIA 驱动将 GL/Vulkan 请求路由到独显 __GLX_VENDOR_LIBRARY_NAME=nvidia — 强制 GLX 使用 NVIDIA 的 vendor 库 适用条件 双显卡（Intel 核显 + NVIDIA 独显）笔记本 已安装 NVIDIA 闭源驱动（nvidia-driver） 桌面环境不限（GNOME / KDE / XFCE 等均可） 操作步骤 1. 修改 .desktop 文件 将系统目录下的 .desktop 文件拷贝到用户目录（避免被系统更新覆盖）： cp /usr/share/applications/google-earth-pro.desktop ~/.local/share/applications/ cp /usr/share/applications/wechat.desktop ~/.local/share/applications/ 修改 Exec 行，在程序路径前加上环境变量： sed -i 's|^Exec=/opt/google/earth/pro/google-earth-pro %f|Exec=env __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia /opt/google/earth/pro/google-earth-pro %f|' \ ~/.local/share/applications/google-earth-pro.desktop sed -i 's|^Exec=/usr/bin/wechat %U|Exec=env __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia /usr/bin/wechat %U|' \ ~/.local/share/applications/wechat.desktop 2. 注销并重新登录 让 GNOME Shell 重新加载 .desktop 文件缓存。 3. 验证 nvidia-smi 启动 Google Earth Pro 和 WeChat 后，应看到类似输出： +-----------------------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=========================================================================================| | 0 N/A N/A 2327 G /usr/bin/gnome-shell 130MiB | | 0 N/A N/A 25233 G ...gle/earth/pro/googleearth-bin 112MiB | | 0 N/A N/A 25399 G ...ns-seed-version --log-level=2 72MiB | +-----------------------------------------------------------------------------------------+ googleearth-bin 为 Google Earth Pro，...ns-seed-version 为 WeChat 的 GPU 子进程。 说明 Chrome 未纳入：日常浏览网页、看视频等场景 Intel 核显已足够，独显无感知收益且徒增功耗发热。如有 3D/WebGL 重负载需求，可自行添加 --use-gl=egl 参数。 环境变量直接写在 Exec 行：避免了对 shell alias 或外部脚本的依赖，桌面菜单点击即可生效。 恢复默认：删除 ~/.local/share/applications/ 下对应的 .desktop 文件即可回到系统默认配置。 为什么不使用独显直连？虽然改成独显直连，桌面都会变流畅，大部分程序都会默认走英伟达独显，比如 telegram-desktop，但是对我来说有一个致命性问题，腾讯会议的视频功能无法使用了，摄像头也无法调用，无法分享桌面，别…

实现了一套Linux下快速查词/翻译句子的工作流-linux-quick-translate
type: item
date: 2026-06-01T10:25:05+08:00
description: GitHub 地址：https://github.com/hellodk34/linux-quick-translate 在 Linux 桌面环境快速查词/翻译句子，绑定系统全局快捷键。支持各种 Linux 发行版和不同的 DE（桌面环境）。详细食用方法请看 GitHub 选中文本 → 复制（ Ctrl+C ）→ 按 Super+C 弹出结果。 单个英文单词：本地 sdcv 词典查询 句子/段落：在线翻译 API 这样在浏览器或者系统中的任何地方阅读英文文献/文章都能快速翻译，复制文章的全部文本也能翻译整篇文章。 截图展示： 欢迎使用！

开发了一个基于和风天气 API 的 Android 天气应用
type: item
date: 2026-06-01T10:06:31+08:00
description: 使用截图 介绍请看 GitHub，这里懒得再写一遍了。地址 https://github.com/hellodk34/checkitout_weather_android

由于 Linux 桌面没有一个好用的天气程序就写了一个跨平台的CheckitoutWeather
type: item
date: 2026-05-25T15:27:00+08:00
description: vibe coding的程序。暂时构建了 win 和 linux 的。mac 没设备暂时。 开源以及下载地址： GitHub ，使用的和风天气API ，由于 API收费，免费的有额度但是不多，所以开源版是无 api auth的。使用了更新的 JWT 认证，更安全，受支持也更久（类似 LTS ），传统的 API KEY 认证方式将很快受到请求量的限制。 功能： 实时天气：温度、体感温度、湿度、降水、气压、风向风力、能见度 昨日天气 + 未来 7 天预报 空气质量 (AQI) 与首要污染物 紫外线指数与等级描述 日出 / 日落时间 城市搜索、收藏管理 亮色 / 暗色主题切换 使用截图如下 欢迎下载使用。

给 caesium-image-compressor 图片压缩程序构建了 Linux AppImage v2.8.5 最新版
type: item
date: 2026-05-21T13:36:00+08:00
description: 欢迎使用 linux 桌面的朋友们使用，构建脚本都开源了，开源在 https://github.com/hellodk34/caesium-image-compressor 原来有一个维护者 https://github.com/larygwil/caesium-image-compressor 但是他停更了，止步于 v2.6.0 ，并且项目没有开启 issues ，于是我就自己来了。 这个图片压缩程序我昨晚用了，傍晚出去拿相机拍了几张照片，压缩了效果很不错，并且保持了原有分辨率。前段时间我常用索尼的 Creators' App 的 2M 传输的选项，虽然每张照片也还能看，并且体积只有 500KB 左右，但是被砍成了 200 万像素…… 以前我都用 squoosh 的，但是 squoosh 做批量压缩搞个好用的 flow 还是比较麻烦和困难的，这个 GUI 程序正中我的口味。原作者构建了 win/macOS 程序，但是缺少 Linux 这边的构建。 使用截图 随机赠送一张昨晚拍的照片 😁