Pi Book Pro

这货吧,其实就是买来玩的…… 技术上来说,这货是一个电池+键盘+触摸板+屏幕(1080p IPS),外带一块控制板。控制板上提供一个 USB-C 和一个 USB-A 接口。连上 USB-C,就可以用里面的键盘、触摸板和屏幕,以及 USB-A 口上的设备。USB-A 口还可以供电。 本来好像是个叫 Superbook 的众筹项目,然而还没发完货就倒闭了…… 于是大概是北美的经销商有一批货,他们就打算卖掉货抵欠款,至少他们是这么说的。 反正这货只要80刀,就这些东西来说还是可以的,于是就搞了一个。 拿来其实想给 Pine64 用,然而直接折腾发现不太行,插上去首先是触摸板不能用,屏幕也不行。插Windows,屏幕倒是即插即用,触摸板还是不行。 搜了搜说要先升级固件(刚来就有问题么……),给触摸板刷新固件。升级完之后,触摸板倒是能用了。Windows 上没啥问题,虽然触摸板有时候有点不灵敏,别的都还行,拿来看片也没问题。 但是插 Pine64 上屏幕还是不行。研究了一波,这货里面其实是个 DisplayLink 芯片(DL-4120),要装驱动的。但是官方驱动搞了一波并不能解决问题,还需要折腾一下: 这个驱动其实是闭源的,然而它有个叫 evdi 的内核模块倒是开源了。这个模块貌似就是个用来让用户态能够虚拟显示器的东西。驱动会尝试自己编译这个,其实这个模块 Debian 的源里也有(evdi-dkms),用源里的就行。 这个驱动主体就是个叫 DisplayLinkManager 的东西,跑在用户态,应该是靠 evdi 来建虚拟显示器。看了眼官方驱动里只有 x86/x64/armhf 的版本,也就是没有aarch64的…… 所以首先要装一堆 armhf 的库,满足依赖。 装完还是不行。一通折腾之后发现还要编译驱动自带的libevdi.so。源里其实也有,但是貌似不能用,可能是版本问题。编译完(需要编译成32位版本,因为DisplayLinkManager也是32位的……)之后再跑,居然就行了。 然后就是咋显示的问题。用的方法和Optimus的差不多:用 xrandr 把另一个显卡的内容输出过来…… 但是我Pine64跑的那个Debian里自己显卡驱动都没装好,不能当源。看了眼其实是没有DRI模块…… 于是干脆升级到unstable。 升级完了 xrandr –listproviders 就能看见俩了,其中一个是自带显卡,可以当源,另一个是 evdi…… 把一个指到另一个,终于有显示了…… 折腾完之后发现,巨卡…… 可能是因为Pine64的显卡驱动(lima)是逆向出来的,性能非常堪忧,再加上重定向显示内容,简直没法用…… …

Continue reading ‘Pi Book Pro’ »

远程音频

之前折腾了远程音频,差不多就是把各个机子的音频转发到另一个机子上,然后在那上面插耳机。好处主要是换机器不用换耳机,全都是一个出口。 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=rtpload-module module-rtp-send source=rtp.monitor destination_ip=<receiver IP> rate=96000set-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 的方法。 …

Continue reading ‘远程音频’ »

鼓包的后续

我已经发过俩关于鼓包的文了,鼓了至少三个平板一个手表了…… 之前也说过,上个设备鼓起来的时候,新平板貌似也开始鼓了。现在过了若干个月,果然它鼓起来了,而且是我各个设备鼓得最厉害的一个,甚至把屏幕上的玻璃膜鼓裂了…… 中间断开来了。另外看了眼换过的Surface Pro 4,果然又鼓起来了。虽然不厉害,但是屏幕左侧开始和背板分离了。放冰箱只能临时缩回去,拿出来过会又鼓起来了,看来也只是热胀冷缩而已。 为了避免重蹈覆辙,我去看了眼这个有什么办法。网上说法基本上就是锂电池长期没电/满电都不太行,时间长了会产生气体鼓起来。解决方法就是保持电量在中间位置。然而谁有兴趣没事情去拔了再过会插回去呢…… 幸好微软是有解决方案的:Surface Pro 3之后的设备,BIOS里有个Kiosk Mode。开了之后会自动维持电量在50%,即使一直插着。于是我就跑去把 Surface Pro 4,Surface Pro 6,以及老的 Surface 3 的这个选项都开了。说起来那个古老的 Surface 3 应该是15年的吧,居然还没事……其他笔记本据说有的也有官方工具能够干类似的事情,虽然我暂时没别的……对于其他设备,有个有趣的小东西可能可以解决问题:有个叫 Chargie 的设备,简单来说就是个蓝牙控制的开关,串联在供电接口上。手机/平板上要装对应的app,装了之后,电量到一定水平就自动控制那个开关关掉,低了再开回来。看上去是不错,本来考虑搞一个。然而这货貌似不支持USB PD,如果用USB-C充电可能有点问题,所以还没下手。不过长期来说,应该就是给所有一直插着的带电池设备都配上这个,例如 Pixel Slate……

多设备蓝牙键盘

这东西倒也没啥新鲜的,罗技基本上现在每个都有这个功能。然而家里键盘并不想换,反正还有个扔着没用的 Pine64,就考虑结合一下变成多设备蓝牙键盘…… 输入嘛就靠libinput。这年头拿个输入还是很方便的,拿python的wrapper随便折腾折腾就有了。 蓝牙比较麻烦。本身蓝牙就比较复杂,要先搞 SDP 记录然后再接收连接。参考了网上直接模拟蓝牙键盘的代码,改改 HID 描述符加上鼠标,加上接收多个连接的功能,搞个快捷键切换设备,也就差不多了。 蓝牙键盘鼠标和 USB 的那套差不多,就是 HID 套个壳。这个倒是比较简单,之前也研究过 HID 描述符和 HID 报告的格式,随便折腾一下就能发送报告了。然而被 Python 3 的 bytes/str 坑了一波,最后发现 0xa1 发送成了 0xc2 0xa1 才注意到这个问题…… 目前倒是折腾到能用,然而蓝牙那块还是有一些诡异的问题。比如说,Android 和 Linux 经常连不上来,看上去 bluez 这边发送的回复是说 Connection pending, Authentication pending,过一会就 fail 了,然而有时候又能跑,还需要更多研究…… 至于为啥不直接用 synergy 或者远程跑个服务器然后发数据嘛…… 因为毕竟蓝牙比较通用,远程不需要啥设置,以及折腾折腾比较好玩…… 说起来折腾这货还发现了奇妙的bug。只要(不)恰当地设置 SDP 记录,Windows一连上就会蓝屏…… KERNEL_SECRUITY_CHECK_EXCEPTION来着。 https://github.com/HenryHu/bthub/tree/master/src

关于一堆可疑的SNMP包

很久以前,我系的CRF(管理计算机资源的)来找过我,说我机子被黑了。我观察之后没啥症状,就问他们为啥那么说。 他们拿出来一个单子,说你机子往外发可疑的包,只有被黑了才发这种包。 我看了一眼,貌似我的机子在广播SNMP包。我觉得这事情也不是那么奇怪,毕竟一堆程序依赖snmp库,但是他们觉得有问题。 于是我在防火墙加了个规则,说如果有这种包就记录一下并且扔掉。其他还干了很多事情,例如换私钥之类,总之很麻烦。之后,他们就不来找我了…… 系统里的确偶尔会记录下这种包的发送记录。那时候尝试看了一眼,没看出为啥,也就没有管。 过了很久之后,一天我看着这些记录,觉得很烦躁,想着干脆研究清楚为啥会发这些破包。 首先,那些个记录里记录了发包者的UID。在我的机子上,记录的UID是colord的UID。 colord是啥呢?可以参见http://www.freedesktop.org/software/colord/intro.html。基本上是个管理色彩配置的东西,如果你不是特别关心你颜色显示得是否准确,其实有没有都无所谓。 colord发SNMP包还是很难让人理解。ldd看一眼,发现colord并没有链接libnetsnmp,net-snmp也不是他的依赖。 观察一下colord的依赖,其他貌似都挺无辜,但是有个可选依赖是sane。我机子上恰好也装了sane。 sane是啥呢?参见http://www.sane-project.org/,Scanner Access Now Easy(这Now是硬插进去的吧!),是个管扫描仪的东西。 sane倒是依赖net-snmp,所以多半是它干的好事。 之后把colord和sane代码扒下来看一眼,大概知道是怎么回事情了。 说colord有个sane插件,嘛大概扫描仪也需要色彩配置。这个插件会启动一个叫colord-sane的程序,这个程序链接到了libsane。sane有个插件叫magicolor,管理Konika Minolta的一个系列的扫描仪。 colord因为某些原因要更新设备列表,于是调进那个插件。插件启动colord-sane,导致sane也让他的插件们更新设备列表。那个magicolor系列扫描仪估计比较高级,能够联网。magicolor插件更新设备列表就去群发SNMP包,在本地网上找这个扫描仪。这个包被CRF看见了…… 其实也怪那个SNMP请求范围太广。他发的SNMP包基本上就是让本地所有的SNMP设备向他报告自己是啥设备,有啥功能之类。这看上去当然挺危险…… 最后说这个过程是怎么触发的。在开始打记录之后,我发现当我插拔手机/平板的时候,那个记录会一起出现。这种事情很容易联想到UDEV,sane和colord其实都装了UDEV规则,而这里引起问题的是colord的规则。那个规则说,只要USB设备插入/拔出,并且有gphoto支持,就给colord发个通知。Android的手机/平板当然在这个范围,于是引发了一系列事件,最后SNMP包就发出去了…… 总体现象是你插拔手机会发SNMP包,谁知道里面有这么一个过程…… 如果有个工具,能够告诉他触发条件和结果,问他中间的因果关系,倒是会方便不少。好像也不是搞不出来,不过貌似没啥学术价值……