Pixel 4 换电池

实话说我对于电池鼓起来已经很习惯了……

所以我看见Pixel 4后盖鼓起来的时候…… 并没有很惊讶……

都鼓起来了 就免得啥加热拆背板了
直接搞定了两条边

说起来我手机还是有壳的…… 这次电池鼓得直接手机从壳里出来了……

鼓起来了么倒也方便 只要用个硬纸板划拉划拉 把剩下俩边也弄开 就可以拆掉背壳了……

多谢iFixit上有拆解教程,照着上面搞就完了。背壳和主板有个排线和插头,电池也有个插头,分别压在俩螺丝固定的金属壳下面,螺丝还是常见的Torx。拆掉螺丝和壳子,再用塑料撬棍把插头撬掉,就可以把背壳拿走了:

可以看见已经挺鼓了……

然后么就是拆电池,电池底下那俩黄色的贴纸就是电池胶条的头。拉住一个使劲拽,就可以把胶拽下来…… 结果我拽一个拽了半天,最后直接把电池一起拽下来了:

胶条真不错,还挺干净……

随后么就是Amazon下单一个电池,两天就到了。看着和原来不太一样,和产品页面不一致啊…… 差评……

然后么就是电池粘回去,插头插回去,螺丝拧回去,盖上背板,就完了。

按理来说是应该再买新的背壳胶水(一圈,就是第一个图里面拉丝的东西……),然后加热粘回去的。但是我反正有手机壳,也不是很在意防水,就靠老的胶水粘着+手机壳固定,也就差不多了。

最后嘛,我只能说:

  1. 一直插电的东西看来迟早要鼓起来,就算是 Google 亲儿子也不例外…… 这也才一年半而已啊……
    1. 这点上 Surface 提供的充电充一半功能就不错,不知道啥时候 Android 平板和手机也能支持……
    2. 除非我迅速淘汰这个手机,否则看来迟早还要再换一次……
  2. 可维修性还是挺重要的。
    1. 我觉得 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),要装驱动的。但是官方驱动搞了一波并不能解决问题,还需要折腾一下:

  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 设备,或许应该从这方面考虑……