Pixel 4 换电池

实话说我对于电池鼓起来已经很习惯了…… 所以我看见Pixel 4后盖鼓起来的时候…… 并没有很惊讶…… 说起来我手机还是有壳的…… 这次电池鼓得直接手机从壳里出来了…… 鼓起来了么倒也方便 只要用个硬纸板划拉划拉 把剩下俩边也弄开 就可以拆掉背壳了…… 多谢iFixit上有拆解教程,照着上面搞就完了。背壳和主板有个排线和插头,电池也有个插头,分别压在俩螺丝固定的金属壳下面,螺丝还是常见的Torx。拆掉螺丝和壳子,再用塑料撬棍把插头撬掉,就可以把背壳拿走了: 然后么就是拆电池,电池底下那俩黄色的贴纸就是电池胶条的头。拉住一个使劲拽,就可以把胶拽下来…… 结果我拽一个拽了半天,最后直接把电池一起拽下来了: 随后么就是Amazon下单一个电池,两天就到了。看着和原来不太一样,和产品页面不一致啊…… 差评…… 然后么就是电池粘回去,插头插回去,螺丝拧回去,盖上背板,就完了。 按理来说是应该再买新的背壳胶水(一圈,就是第一个图里面拉丝的东西……),然后加热粘回去的。但是我反正有手机壳,也不是很在意防水,就靠老的胶水粘着+手机壳固定,也就差不多了。 最后嘛,我只能说: 一直插电的东西看来迟早要鼓起来,就算是 Google 亲儿子也不例外…… 这也才一年半而已啊…… 这点上 Surface 提供的充电充一半功能就不错,不知道啥时候 Android 平板和手机也能支持…… 除非我迅速淘汰这个手机,否则看来迟早还要再换一次…… 可维修性还是挺重要的。 我觉得 Pixel 4 换电池还算容易,毕竟主要难点也就是那圈胶水,为了拆电池还提供了容易移除的胶条,还行。 下一个谁会鼓起来呢…… 我觉得那个手表就挺有希望的?毕竟一年都没咋出去一直充着电…… 当然 Pixel Slate 感觉也很有戏…… 也是一直插着从不拔的那种……

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 ‘远程音频’ »

tmux 和剪贴板

tmux 支持鼠标,甚至支持选一段东西之后自动发给剪贴板。这个功能很好用,比如在想从终端贴一段文字到浏览器的时候之类…… 然而这个功能有时候需要一些配置。折腾一波之后,发现主要是这么几个部分: 首先 tmux 需要打开鼠标支持,并且让它在复制完之后去设置剪贴板: set -g mouse onset -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 …

Continue reading ‘tmux 和剪贴板’ »

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的延时和远程音频的关系。结果发现,只要一开始播放音乐,延时就涨到几百,只要一停,过一会就掉回几十…… 既然怀疑就是多播的问题,那干掉多播就完了。我把远程音频都改成了单播的,幸好这俩都可以改。改完之后到现在已经三天了,目前看来还没啥问题…… 搞完之后回头想想,说不定本来的路由就没问题呢?……