Pi Book Pro

这货吧,其实就是买来玩的……

技术上来说,这货是一个电池+键盘+触摸板+屏幕(1080p IPS),外带一块控制板。控制板上提供一个 USB-C 和一个 USB-A 接口。连上 USB-C,就可以用里面的键盘、触摸板和屏幕,以及 USB-A 口上的设备。USB-A 口还可以供电。

本来好像是个叫 Superbook 的众筹项目,然而还没发完货就倒闭了…… 于是大概是北美的经销商有一批货,他们就打算卖掉货抵欠款,至少他们是这么说的

反正这货只要80刀,就这些东西来说还是可以的,于是就搞了一个。

拿来其实想给 Pine64 用,然而直接折腾发现不太行,插上去首先是触摸板不能用,屏幕也不行。插Windows,屏幕倒是即插即用,触摸板还是不行。

搜了搜说要先升级固件(刚来就有问题么……),给触摸板刷新固件。升级完之后,触摸板倒是能用了。Windows 上没啥问题,虽然触摸板有时候有点不灵敏,别的都还行,拿来看片也没问题。

但是插 Pine64 上屏幕还是不行。研究了一波,这货里面其实是个 DisplayLink 芯片(DL-4120),要装驱动的。但是官方驱动搞了一波并不能解决问题,还需要折腾一下:

  1. 这个驱动其实是闭源的,然而它有个叫 evdi 的内核模块倒是开源了。这个模块貌似就是个用来让用户态能够虚拟显示器的东西。驱动会尝试自己编译这个,其实这个模块 Debian 的源里也有(evdi-dkms),用源里的就行。
  2. 这个驱动主体就是个叫 DisplayLinkManager 的东西,跑在用户态,应该是靠 evdi 来建虚拟显示器。看了眼官方驱动里只有 x86/x64/armhf 的版本,也就是没有aarch64的…… 所以首先要装一堆 armhf 的库,满足依赖。
  3. 装完还是不行。一通折腾之后发现还要编译驱动自带的libevdi.so。源里其实也有,但是貌似不能用,可能是版本问题。编译完(需要编译成32位版本,因为DisplayLinkManager也是32位的……)之后再跑,居然就行了。
  4. 然后就是咋显示的问题。用的方法和Optimus的差不多:用 xrandr 把另一个显卡的内容输出过来……
  5. 但是我Pine64跑的那个Debian里自己显卡驱动都没装好,不能当源。看了眼其实是没有DRI模块…… 于是干脆升级到unstable。
  6. 升级完了 xrandr –listproviders 就能看见俩了,其中一个是自带显卡,可以当源,另一个是 evdi…… 把一个指到另一个,终于有显示了……

折腾完之后发现,巨卡…… 可能是因为Pine64的显卡驱动(lima)是逆向出来的,性能非常堪忧,再加上重定向显示内容,简直没法用…… 一开始开着 compositor,打字都要等…… 后来关了,稍微好了点,但基本还是不能用。

所以他叫PiBookPro是有原因的,可能还是要Raspberry Pi 3/4的显卡性能才够用……

当然,这货还可以有很多别的用处。例如 Windows/ChromeOS 都是即插即用,Linux 的话装驱动也不难。虽然我各种系统都有显示设备了,所以暂时没啥用…… 以后搞个新一点的小板子来连上去吧,毕竟 Mali-400 是08年的显卡……

另外,貌似电池完蛋了,不过无所谓了……

远程音频

之前折腾了远程音频,差不多就是把各个机子的音频转发到另一个机子上,然后在那上面插耳机。好处主要是换机器不用换耳机,全都是一个出口。

Windows 的发送靠 Scream (https://github.com/duncanthrax/scream),可以把音频发送到网上的接收端。Windows 这边是个驱动,也有各种客户端可以收。默认是多播,注册表改改就能单播了……

Linux 靠的是 Pulseaudio 的 rtp send/recv。其实挺简单的,就是弄个 rtp sink 作为默认音频 sink,然后把这个 sink 的收到的东西用 rtp-send 发出去:

load-module module-null-sink sink_name=rtp
load-module module-rtp-send source=rtp.monitor destination_ip=<receiver IP> rate=96000

set-default-sink rtp

接收端么弄个 rtp-recv,就行了:

load-module module-rtp-recv sap_address=<receiver IP>

就像我之前说的,默认这货会用多播,然后导致一些 WiFi 问题…… 所以要指定 IP 才行。

FreeBSD 嘛比较麻烦点。首先,支持 Pulseaudio 的程序可以按 Linux 一样处理。然而,有些程序就认基础的 oss,打开 /dev/dsp 就用……

对这种东西当然可以用padsp,不过这货好像有点bug,不太行。我找了个结合 virtual_oss 和 Pulseaudio 的方法。

首先用 virtual_oss 模拟一个 /dev/dsp 出来,把收到的东西从另一个 loopback dsp 发出去:

virtual_oss_enable="YES"
virtual_oss_dsp="-T /dev/sndstat -S -c 2 -r 48000 -b 24 -s 8ms -l dsploop -f /dev/null -d dsp -t dsp.ctl"

然后让 Pulseaudio 把这个 loopback dsp 收到的东西发给 rtp:

load-module module-oss device=/dev/dsploop sink_name=dsploop_sink source_name=dsploop_source
load-module module-loopback latency_msec=1 source=dsploop_source sink=rtp

然后就搞完了。延迟还能接受,应该还是略高。

说到延迟,Pulseaudio 的延迟好像总是不小,Scream 就几乎没有。估计和 buffer 多大有关系吧……

最后,Android 设备目前还没啥想法…… 考虑到 Android 支持 USB Audio 设备,或许应该从这方面考虑……

tmux 和剪贴板

tmux 支持鼠标,甚至支持选一段东西之后自动发给剪贴板。这个功能很好用,比如在想从终端贴一段文字到浏览器的时候之类……

然而这个功能有时候需要一些配置。折腾一波之后,发现主要是这么几个部分:

首先 tmux 需要打开鼠标支持,并且让它在复制完之后去设置剪贴板:

set -g mouse on
set -g set-clipboard on

然而这并没完。所谓“设置剪贴板”,其实就是发一段东西给外面的终端模拟器(tmux 归根结底只是发各种东西给终端模拟器而已……),说“设置剪贴板为XXX”。这段东西就是OSC 52。OSC就是“operating system command”,就是某种终端控制序列,用来和系统交互的…… OSC 52 就是里面的命令52,功能是设置剪贴板。

然而 tmux 其实依赖某些信息来告诉他“外面这个终端模拟器支持OSC 52”。这个就是 terminfo 里面的 Ms 能力(属性?)。这个告诉了 tmux,要设置剪贴板应该发什么格式的东西给终端模拟器。

然而我现在用的 term(st-256color)里面貌似并没有这个…… 结果就是就算开了上面这俩,tmux 也不干活。

正确的修正方法当然是把那个属性加进 terminfo,但是这个挺麻烦的,而且每个系统都要加…… 理想状况下我可以只用 tmux.conf 解决问题。

解决方法当然是有的:直接在 tmux.conf 里面修改 terminfo 给的结果…… 所以可以直接告诉 tmux,对某些 terminal(我这里是st*),设置剪贴板就发这个:

set -g terminal-overrides[2] 'st*:XT:Ms=\E]52;%p1%s;%p2%s\007'

我其实还添加了 Tc,所以怎么样都认为支持24位色…… 不过这就是另一个事情了。

搞了这俩之后,tmux 就会发送 OSC 52 了。

最后还有终端模拟器收到这个之后需要设置剪贴板。我现在用的 suckless terminal 是支持的(虽然默认 buffer 大小比较小,所以长一点的文字会被截断,不知道修了没……)。很多别的也是支持的……

这么搞剪贴板支持有如下好处:

1. 远程也能用

ssh 过去之后,选一段东西,也能够很好的复制进本地的剪贴板里面,因为一路传回来了。如果是在 tmux 里面用一个脚本处理鼠标事件之类可能就不行。

2. 分栏也能用

如果用终端模拟器自己的复制功能,那 tmux 分栏的时候就会复制一堆啥分栏符之类的进去。用 tmux 自己的鼠标支持就没这个问题。

3. 简单

只要随便搞几行 config 就完了,不像某些剪贴板支持搞法那么麻烦,又是 binding 又是脚本的……

WiFi 与多播

最近折腾了一波 WiFi……

起因是老的 Netgear R6250 路由的无线好像有点问题。一开始是2.4G有问题,于是我拿出了一个 TP-Link 的小路由来对付2.4G。其实我家普通设备也不用2.4G,也就是那些破智能家居的东西,啥灯泡开关之类,还有啥打印机啦 Kindle啦,这些破烂没法用5G。症状是这些设备时不时就掉线,看看路由的设备列表也会发现大多数2.4G设备都消失了。ping 也不通,出问题的时候尝试手机连2.4G也连不上。

后来我刷了一波 dd-wrt(OpenWrt 没有 5G 支持),结果更糟糕了,有时候直接断网…… 虽然估计是dd-wrt的问题,但是也懒得再刷回去了,反正也有问题。

于是想想这个路由也用了5年了,干脆买个新的。毕竟快要 WiFi 6 (802.11 ax) 了嘛,要买就买支持AX的。等了一段时间的折扣,搞来一个 Netgear AX5200。

买来之后用了没几天,发现2.4G问题依旧…… 症状也差不多,反正就是设备会掉。根据经验么,我就开始折腾路由的各个设置,例如看看哪个频道空啦,改改无线信号频率宽度啦,改改各种WiFi设置啦…… 结果改完居然5G都出问题了,时不时会卡上个半分钟一分钟的,卡完之后ping能收到一堆延时了最多半分钟的包。于是只好恢复出厂设置,然后5G好歹恢复了,所以真的是改设置改出问题了……

所以回头看2.4G相关设置,实在是没啥搞头…… 频道么,公寓楼里每个频道都一堆信号,干扰总是免不了的。然而就算这样,应该也不至于就没法用……

没办法只能拉出来Wireshark抓包,看看有啥希望没有。在2.4G有问题的时候,抓包发现路由偶尔还是能吐出来几个包的,多数都是多播……

于是这个时候我意识到这个可能就是问题:2.4G应该没有设备要听这个多播啊……

说到这个多播吧,其实是远程音频的副产品。因为多个设备都需要播放音频,而我又不想把耳机来回拔插,于是在各个系统都搞了远程音频,各个系统都把音频发到一个机子上。Linux/BSD用的是PulseAudio rtp send/recv,而Windows用的Scream。

这俩底下其实貌似都是RTP,以及都是用的多播。多播这个东西有线网是挺合理的,无线网就比较堪忧了。有些路由器甚至有自动把多播转成单播的功能。一般来说普通用户也没这个需求,所以 Netgear 没在普通路由器做这个也很合理……

虽然吧,还是有些奇怪的。多播应该是要主动申请加入(通过IGMP)的,而那些2.4G的设备显然不会去加入。既然这样,那路由不该把这些多播包发给它们啊……

为了证实是多播的问题,我观察了一下ping的延时和远程音频的关系。结果发现,只要一开始播放音乐,延时就涨到几百,只要一停,过一会就掉回几十……

既然怀疑就是多播的问题,那干掉多播就完了。我把远程音频都改成了单播的,幸好这俩都可以改。改完之后到现在已经三天了,目前看来还没啥问题……

搞完之后回头想想,说不定本来的路由就没问题呢?……