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 又是脚本的……