欢迎留言、转载请注明出处
最近趁着国补+以旧换新优惠，更新了下显示器，换掉了用了8年的傻多戴U2518DR（现在看当年真的是傻多了，2500的价格，只为一个2k，没有高刷，所谓的HDR还是个假的） ，改投了国产泰坦军团的高性价比型号P275MV PLUS。4K 160HZ，1080 320HZ双模切换，Mini LED 1152分区HDR1000，还带TYPE-C PD 65W快充和USB集线器，光感自动亮度，内置音箱等功能，可以看到这8年显示器技术有了多大的提升，可以说是鸟枪换了炮。其实这款型号当初刚上的时候就关注到了，那时本来想买败家之眼XG27UCG，但刚需PD快充一直没下手，同时泰坦这款上市后价位和UCG差不多，对于国产品牌来说感觉还是有点贵。但这不最近国补一上，性价比就出来了，以旧换新出了Dell后也就1000出头，没啥好说的，果断换了！
这次记录的是换后折腾高刷，Windows 11 DRR（动态刷新率），DSC（Display Stream Compression），G-Sync（VRR，对应到这款显示器的是Adaptive Sync技术）的一些总结：
Continue reading…
Qt GUI程序封成动态库方式，供其他非Qt程序加载使用时，遇到一个GUI初始化并显示时，大概10s后程序崩溃的问题，调用栈显示崩溃在主线程的NSPersistentUIRequiresSecureCoding函数调用中，如下图所示：
经过排查以及互联网搜索，发现了Qt论坛上有人问到了类似问题：https://forum.qt.io/topic/159548/building-a-dll-on-macos-for-a-non-qt-application/7，原来Qt GUI在以库方式加载使用时，还要设置额外的初始化标识：
QGuiApplication::setAttribute(Qt::AA_PluginApplication);
QGuiApplication::setQuitOnLastWindowClosed(false);
主要是上面的Qt::AA_PluginApplication，看来Qt内部有针对这种plugin方式使用的特殊处理逻辑，加上这个attribute后，再次测试，就不再崩溃了。
最近在测试Xcode原生Mac Cocoa GUI应用中直接调用Qt GUI时遇到了一个报错找不到native plugin的问题。先记录下操作系统是：macOS 13.4，Xcode版本是：Version 14.3 (14E222b)，Qt版本是：6.8.0。用法是在Xcode中新建一个App，interface选的xib（但应该没关系，因为根本没用任何xcode GUI编辑功能），然后在生成的的代码项目中手动加入各种依赖的Qt Framework，并设置好include，lib，rpath等各种路径。代码也是从网上搜到的很简单的创建Qt空间后，通过winId的方式（这是Qt6新改的，以前的Qt5及旧版本需要使用QMacNativeWidget）挂到NSView下，如下：
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
// Insert code here to initialize your application
QPushButton* btn = new QPushButton("testtttttttttttt");
NSView* viewBtn = (__bridge NSView*)((void*)btn->winId());
[self.window.contentView addSubview:viewBtn];
btn->show();
[viewBtn setNeedsDisplay:YES];
[self.window makeKeyAndOrderFront:self.window];
}
需要注意的是开了ARC后的winId返回到NSView*的cast，c cast，c++ cast直接用都不行，查了半天才找到这种__bridge cast配合强转void*的可行方式。
然后运行，发现了标题中的报错信息：
Continue reading…问题现象如下：
[root@ci1 ~]# docker image pull wzkres/centos-ci-gcc:centos-7-cross-arm64
centos-7-cross-arm64: Pulling from wzkres/centos-ci-gcc
2d473b07cdd5: Already exists
9d26d6802cad: Pull complete
90f6d29b7c1a: Pull complete
7bfff1b24796: Pull complete
80b3d4546432: Pull complete
c3a37398e8b3: Pull complete
3ba42b3a770d: Pull complete
85b3405c69c4: Downloading
2ad9c2d42a3d: Waiting
5f1b06925eb4: Waiting
4f4fb700ef54: Waiting
57c257cf6173: Waiting
787f48d693d2: Waiting
9f1677804e77: Waiting
c13fd6dc43b4: Waiting
80bd40938514: Waiting
56ba96a89fa8: Waiting
unauthorized: authentication required
在从hub.docker.com拉取公开镜像时，频繁出现标题中提到的错误而失败，出现时间随机，且出现频率非常高，导致稍大些的镜像几乎无法顺利完成下载。一开始以为是网络问题，各种更换“科学”，使用镜像代理均没什么效果，看提示的是“authentication”，还以为是docker hub登录信息的问题，于是也试过docker login -u xxxx，无果…
Continue reading…最近在研究基于STM32F103CBT6单片机的USB HID鼠标设备实现，电路部分主要抄自各开源实现，今天要记录的主要是单片机软件方面的问题：测试阶段发现如果在开机前先插好USB鼠标，再开机，有一定概率出现鼠标操作没反应的情况！并且这个现象在我的笔记本（联想thinkbook 14+，支持关机USB充电）上要比台式机（技嘉X570+5700x，前置USB）上出现几率高不少，基本上开3次就能有1次出现这种情况。
先说明下，MCU软件部分主要基于ST的“STM32F10x, STM32L1xx and STM32F3xx USB full speed device library (UM0424)” https://www.st.com/en/embedded-software/stsw-stm32121.html USB库实现，里面有HID实现的例子，基本都是照抄的，改了下Joystick例子的USB描述符，报文相关参数（3按键+1滚轮+XY移动，1ms轮询）。电路部分，一开始实验的时候用的是合宙的AIR32F103，对比STM32F103，支持USB DP的内部1.5k上拉，自己画板制作的时候由于STM32F103没有内部DP上拉，于是简单做了个固定1.5k到3.3v的上拉，做这个设计的过程中已经查到过有些资料参考ST-LINK的设计，应该使用一个GPIO口，通过加NPN开关三极管方式驱动这个1.5k上拉，用于遵守USB 2.0规范约定的设备可枚举信号，同时也根据这个wiki的描述：https://stm32world.com/wiki/STM32_USB_Device_Renumeration ，实测这种通过将DP端口改为PP输出，并拉低50ms左右的非标准做法，也可以实现控制枚举、软件重枚举的功能。于是就没做类似ST-LINK的设计，所以一开始发现标题问题时，以为是这种非标准的USB枚举初始化导致，但是后来通过观察出现问题时的串口日志发现USB初始化枚举都正常，只是在等待轮询取上报数据时出现了问题！
研究了一番后，找到了一个简单的解决方法，加了个超时重置标识变量的方法，如下：
Continue reading…还是先说下环境，系统是CentOS 7.9（怕玩坏了，用的docker，官方镜像centos:centos7.9.2009），配合ARM官方的linux工具链gcc-arm-8.3-2019.03-x86_64-aarch64_be-linux-gnu.tar.xz（这里： https://developer.arm.com/downloads/-/gnu-a），解压到了 /usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu，使用环境变量：
export AR="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-ar" export AS="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-as" export CC="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc" export CXX="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-g++" export RANLIB="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-ranlib" export STRIP="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-strip" export PATH="/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin:$PATH"
来指定交叉编译工具链，依赖的libsamplerate库版本是：0.2.2，报错信息如下：
Continue reading…/usr/local/ARM-toolchain/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/../lib/gcc/aarch64-linux-gnu/8.3.0/../../../../aarch64-linux-gnu/bin/ld: /usr/lib64/libm.so: error adding symbols: file in wrong format
最近发现Proxmox VE 7的管理页面开始提示支持到期的红字了（查了下，官方说明是24年7月底正式停止），于是趁最近有空给服务器升级到了8，开始前仔细研读了官方的大版本升级说明：https://pve.proxmox.com/wiki/Upgrade_from_7_to_8，这个wiki提到了两种升级方式，一是全新安装一个8，然后将原有的磁盘配置和虚拟机通过备份、还原等方式迁移过去，另一种是就地升级，类似系统内软件的升级方式apt update，apt upgrade这样。
从操作方式上来看，感觉第一种方式安全系数更高一些，但是需要有两个服务器，至少是两套一模一样的磁盘环境，新部署的新版本虚机系统如果遇到问题，旧的不受影响，还可以用，新的研究好了，旧的一停，切割完成！第二种方法呢，风险就大一些，一旦升级出现问题，虚机的服务就会中断，而且还需要重装，再还原备份等等麻烦的操作。不过对于博主我来说，也只有第二种就地升级是可行的，因为没有富裕的硬件资源。
虽然升级前感觉做足了功课，但升级过程中还是挺坎坷的，其中坑最大的就是标题上写的这个networking.service/start卡死问题，最早发现问题的症状是在升级正常完成后，重启系统，然后就卡在这个状态：
一开始还傻等了半天，后来发现硬盘灯根本不亮了，才意识到出事了，于是上网搜了一下，发现果然有不少遇到类似问题的人，其中下面这篇文章提到了这个卡住界面背后的实际问题：“Job networking.service/start running”
Continue reading…首先，简单说明下问题情境，一共三个代码文件，一个主执行程序，两个动态库程序，结构与之前写的弱符号，weak symbol一致：
#include <string>
std::string g_name;
void init_name_lib1()
{
g_name = "lib1";
}
const char* get_name_lib1()
{
return g_name.c_str();
}
#include <string>
std::string g_name;
void init_name_lib2()
{
g_name = "lib2";
}
const char* get_name_lib2()
{
return g_name.c_str();
}
#include <iostream>
void init_name_lib1();
void init_name_lib2();
const char* get_name_lib1();
const char* get_name_lib2();
int main()
{
init_name_lib1();
init_name_lib2();
std::cout << "name from lib1: " << get_name_lib1() << std::endl;
std::cout << "name from lib2: " << get_name_lib2() << std::endl;
return EXIT_SUCCESS;
}
首先说明下代码结构：一共三个源码，两个动态库so的源码：lib1.c和lib2.c，各导出一个库函数（gcc编译时默认导出，不像windows的msvc要明确指定导出dllexport），一个主执行程序源码：main.c，调用两个动态库的导出函数，如下：
lib1.c
#include <stdio.h>
void lib1_func(const char* from)
{
printf("lib1 func from %s\n", from);
}
lib2.c
#include <stdio.h>
void lib2_func(const char* from)
{
printf("lib2 func from %s\n", from);
}
main.c
#include <stdio.h>
void lib1_func(const char* from);
void lib2_func(const char* from);
int main()
{
printf("hello from main\n");
lib1_func("main");
lib2_func("main");
return 0;
}