继去年10月第一次修我的樱桃MX2.0S RGB键盘(🫴3年多的樱桃Cherry MX2.0S RGB键盘灯效故障修复记录)灯珠故障后,最近又发现有一组按键(数字小键盘的9、6、3、DEL)出现了同样的故障:

这次手没有抖😂,并且拔了键帽,拍了个视频,故障现象是一清二楚!
由于有上次维修这个故障的经验,所以这次准备优化下维修流程,并记录下简化后的操作流程。
Continue reading…欢迎留言、转载请注明出处
继去年10月第一次修我的樱桃MX2.0S RGB键盘(🫴3年多的樱桃Cherry MX2.0S RGB键盘灯效故障修复记录)灯珠故障后,最近又发现有一组按键(数字小键盘的9、6、3、DEL)出现了同样的故障:

这次手没有抖😂,并且拔了键帽,拍了个视频,故障现象是一清二楚!
由于有上次维修这个故障的经验,所以这次准备优化下维修流程,并记录下简化后的操作流程。
Continue reading…博主的这把樱桃键盘是22年4月京东Cherry搞秒杀活动时抢到的一个红轴RGB键盘,一直放在公司使用至今。在这个国产机械键盘狂卷的时代,MX2.0S感觉除了“樱桃Cherry”之名外,也没有什么特别之处了,不过,我用了这么多年感觉还是挺不错的,尤其喜欢的是这个键盘的配列,右上角的几个快捷键,计算器,媒体播放,上一曲下一曲非常的实用,相对的家里的杜伽K310 RGB的配列就没这么方便了(杜伽是先于樱桃买的)。

然而,最近偶然发现键盘的PAUSE、PAGE UP、C这三个键的背光灯一直亮着红色,一开始以为是误操作了什么灯效配置,于是又是装驱动(没错,这么多年我一直没装Cherry的驱动),又是FN+PAUSE重置的,搞来搞去还是没能恢复,于是我意识到可能是硬件故障了(下面这张拍的时候抖了下模糊了,勉强可以看到常红的三键😂)!

26.4.26,又有一组灯珠出现了同样的故障,正好补上一张看的清楚的症状图(这个mx2.0s的灯珠耐久度可是真不行):

趁着10.1放假时间,把键盘带回家中拆开研究了一番(顺带做了下卫生,这个ABS的键帽3年多下来常用的几个键已经打油了,而且内部也布满了这些年留存下来的“宝藏”😂)。
Continue reading…最近在学习Qt RHI图形渲染框架时遇到了一个奇怪的问题:QRhiGraphicsPipeline莫名其妙的create返回false!因为在出现这个问题的过程中,一直在调试fragment shader,并且是在研究HDR显示shader,期间频繁开关Windows的HDR显示开关,一度以为是系统出现了问题,于是尝试切换了SDR,也依然报错。
后来,花了一些时间revert修改,最后隔离出了问题所在。。。
首先,说明下程序框架基本抄自Qt官方文档中的例程:https://doc.qt.io/qt-6/qtgui-rhiwindow-example.html,重点标记下报错代码位置,在这里:
Continue reading…24年2月左右把用了十来年的Mac Book Air 2013以旧换新换了个联想的ThinkBook14+ 2024 U7版(认证型号:ThinkBook 14 G6+ IMH),用了一段时间,感觉除了做工略显粗糙(屏幕转轴不对称、C面键盘不平等等)外,功能性能方面还挺不错。由于平时主要用家里台式机,所以这个本大部分时间处于待机状态,可是,最近发现这个本关机状态电池电量掉的有点快,平均一天会掉1%-3%,网上搜索了下,发现很多笔记本用户都有报告类似问题的,比如:https://learn.microsoft.com/zh-cn/answers/questions/5562378/win11,https://tieba.baidu.com/p/7795883672,等等还有很多…可以看到,这些笔记本电脑,关机后电池持续好点,并且Win11系统中的电池使用情况记录中能看到关机时间段的屏幕打开时间基本是24小时!
Continue reading…先说下背景,一个gitlab的代码项目,其中以submodule方式引用了同gitlab实例里其他group内的项目,.gitmodules文件内容类似这样:
[submodule "lib1"]
path = lib1
url = http://gitlab.xxx.xxx/group1/lib1.git
[submodule "lib2"]
path = lib2
url = http://gitlab.xxx.xxx/group2/lib2.git
[submodule "lib3"]
path = lib3
url = http://gitlab.xxx.xxx/group3/lib3.git
这个结构在本地开发时子模块管理操作没有任何问题,当然本地的gitlab账号是有依赖的几个子模块代码仓库访问权限的。而在搭建项目CI构建环境时,linux系统使用的是gitlab的docker runner方式,没有任何问题,而在mac系统却遇到了无法初始化submodule的错误问题(使用的是shell runner方式):
Continue reading…最近在尝试国产Linux操作系统麒麟V10(SP1),由于主力敲代码机器还是Windows,所以需要搭建一个远程编译、调试的开发环境,毫无疑问,Visual Studio Code是一个很好的选择,之前也挺轻松的搭建过配合CentOS、Ubuntu系统的远程编译调试环境,不过这次搭麒麟系统却踩了个坑:
Failed to set up socket for dynamic port forward to remote port
VSCode在setup remote时,下载安装server都没问题,但是后面就会报上面的错。网上搜索了下,发现是sshd服务没有开启AllowTcpForwarding导致的,于是:
sudo vi /etc/ssh/sshd_config
找到AllowTcpForwarding,将参数值调整为yes,当然如果是注释状态还要取消注释,然后重启sshd服务:
sudo systemctl restart ssh
重启后,再次尝试,结果报错依旧。研究了一番后发现这个问题在网上并不罕见,但大部分都围绕的是上面提到的这个配置项。不知道是不是麒麟系统的ssh服务默认配置与其他常见发行版不同,最终发现这个问题出在sshd_config中的PermitOpen这个配置,将它设置为any,重启服务后问题解决!
这次要记录的感觉是个比较硬核的问题,限于标题字数限制,没法准确表达出所有问题,比如,调试断点单步跟踪FFmpeg代码时,代码不按顺序执行,满处乱飞,断点位置查看周围局部变量,不能正常显示值,比如这样:

局部变量offset无法显示当前值,而是显示“Variable is optimized away and not available.”的信息,看字面意思可以猜到,代码被编译器做了优化了,比如直接内联省去中间变量,所以看不到了。
但是,FFmpeg的构建configure参数确实设置了
–disable-optimizations –enable-debug –disable-stripping
这些官方说明的构建debug版的参数,怎么实际调试的时候还是会出现上面描述的种种看起来是代码被优化了造成的调试跟踪障碍呢?
Continue reading…最近在学习AD24的过程中,发现一个问题:

如截图所示,AD的DRC检查,报告了一个“[Minimum Solder Mask Sliver Constraint Violation] IP2369_EVM.PcbDoc Advanced PCB Minimum Solder Mask Sliver Constraint: (0.0998mm (3.929mil) < 0.1mm (3.937mil)) Between Pad U1-21(52.014mm,25.561mm) on Top Layer And Pad U1-22(52.014mm,25.961mm) on Top Layer [Top Solder] Mask Sliver [0.1mm]”的错误。
排查了一番,又手工计算了一下焊盘大小、阻焊扩展大小以及焊盘间距:
Continue reading…
不知什么时候开始(严重怀疑是某次Windows 11更新后),OneDrive在“此电脑”中突然出现了两个一摸一样的快捷链接图标,虽然我基本也不怎么用MS的这个网盘吧,但每次打开我的电脑都看到这么个神奇的存在,着实有点碍眼,于是决定“处理”一下这个问题。
Continue reading…