令人难以置信的壁纸更换体验:
系统设置 -> 壁纸
-> 弹出使用条款,点拒绝。看似进入了一个简化的壁纸设置界面
-> 点击 "本地图片"
-> 再次弹出使用条款,必须同意否则无法继续
-> 同意使用条款后弹出权限申请,允许访问照片、视频、音频
然后令人匪夷所思的事情发生了:
Couldn't open this page. Wait a minute or two and try again.
W T F ???
清除「Themes」应用数据后再试一次,这次一开始就同意使用条款
-> 进入了一个内容更丰富的壁纸设置界面
-> 有 在线壁纸、编辑精选 等一堆乱七八糟的选项,但就是没有 "本地图片" ?!?
Side note: 虽然我用 Nova Launcher 可以直接设置桌面加锁屏壁纸,但锁屏壁纸不知道为什么一段时间后会被重置为默认。所以尝试通过系统自带入口设置壁纸。
#trash #china #phone #xiaomi
系统设置 -> 壁纸
-> 弹出使用条款,点拒绝。看似进入了一个简化的壁纸设置界面
-> 点击 "本地图片"
-> 再次弹出使用条款,必须同意否则无法继续
-> 同意使用条款后弹出权限申请,允许访问照片、视频、音频
然后令人匪夷所思的事情发生了:
Couldn't open this page. Wait a minute or two and try again.
W T F ???
清除「Themes」应用数据后再试一次,这次一开始就同意使用条款
-> 进入了一个内容更丰富的壁纸设置界面
-> 有 在线壁纸、编辑精选 等一堆乱七八糟的选项,但就是没有 "本地图片" ?!?
Side note: 虽然我用 Nova Launcher 可以直接设置桌面加锁屏壁纸,但锁屏壁纸不知道为什么一段时间后会被重置为默认。所以尝试通过系统自带入口设置壁纸。
#trash #china #phone #xiaomi
🤯1💩1
媒体控制键 play/pause, next, previous 竟然不属于 hid 键盘按键 🤔
初步 ctrl+f 了一下 hid 标准里好像没有,但是 hid usage table 的 *Consumer Page (0x0C)* 小节里面给了相关的 usage id 。就是不知道从哪、以什么形式发这些 usage id (
初步 ctrl+f 了一下 hid 标准里好像没有,但是 hid usage table 的 *Consumer Page (0x0C)* 小节里面给了相关的 usage id 。就是不知道从哪、以什么形式发这些 usage id (
tinyusb 真的让我高血压,host stack 跟 device stack 一样写了一通刷上去一跑不亮 🤷。根本就不知道为什么,只能对着样例把不一样的地方全部复制过来再逐行排查,看看自己原来漏了哪个关键指令……
边界条件之场
磕磕碰碰好几天终于把 tinyusb device stack 跑通了。 不仅是第一次写 c ,还要学 cmake 。 然后又因为 tinyusb 文档网站上没有文档,不得不在六七个头文件之间跳来跳去尝试理解它的 api 怎么用。 tusb 作者让人去看样例,但样例里面非常离谱地写着 TODO。 changelog 里写着新 api 代替了旧 api,但实际上新 api 不工作 😤 P1: 被 tinyusb 骗( P2: 样例里写着 TODO
边界条件之场
tinyusb 真的让我高血压,host stack 跟 device stack 一样写了一通刷上去一跑不亮 🤷。根本就不知道为什么,只能对着样例把不一样的地方全部复制过来再逐行排查,看看自己原来漏了哪个关键指令……
浪费了非常多时间排查问题,最后干脆直接编译样例,发现样例也跑不起来。
插拔数据线时多看了一眼面包板上的接线,发现用来充当 host 的接口的 vbus 实际上没接电……才突然想起来上周好像临时改了接线,忘记改回来了。
很想扇自己两巴掌 🤡
插拔数据线时多看了一眼面包板上的接线,发现用来充当 host 的接口的 vbus 实际上没接电……才突然想起来上周好像临时改了接线,忘记改回来了。
很想扇自己两巴掌 🤡
边界条件之场
确认供电正常了以后样例还是跑不起来 🤔
啊 WTF ……
我可以选择两个版本的 pico-pio-usb:
- 直接从作者 github 上拉取
- pico-sdk 捆绑的 tinyusb 又捆绑的 pico-pio-usb
后者的版本比前者旧。但看在树莓派 pico 官方跟 tinyusb 官方打包的份上我以为它的整合性会更好(经过测试之类的)。
刚才我本来已经要理智丧失了,稍微冷静下来一点去基于两个版本分别编译了样例,发现 github 版能跑而 pico 打包版不能 🫠🫠🫠
原来不是我的软硬件有问题啊 #wtf
我可以选择两个版本的 pico-pio-usb:
- 直接从作者 github 上拉取
- pico-sdk 捆绑的 tinyusb 又捆绑的 pico-pio-usb
后者的版本比前者旧。但看在树莓派 pico 官方跟 tinyusb 官方打包的份上我以为它的整合性会更好(经过测试之类的)。
刚才我本来已经要理智丧失了,稍微冷静下来一点去基于两个版本分别编译了样例,发现 github 版能跑而 pico 打包版不能 🫠🫠🫠
原来不是我的软硬件有问题啊 #wtf
边界条件之场
啊 WTF …… 我可以选择两个版本的 pico-pio-usb: - 直接从作者 github 上拉取 - pico-sdk 捆绑的 tinyusb 又捆绑的 pico-pio-usb 后者的版本比前者旧。但看在树莓派 pico 官方跟 tinyusb 官方打包的份上我以为它的整合性会更好(经过测试之类的)。 刚才我本来已经要理智丧失了,稍微冷静下来一点去基于两个版本分别编译了样例,发现 github 版能跑而 pico 打包版不能 🫠🫠🫠 原来不是我的软硬件有问题啊 #wtf
用上了阳间版本的依赖后 host stack 很快就跑通了 😌
测试 hid 键盘报文
测试 hid 键盘报文
Ctrl-Shift-C, Ctrl-Shift-V :( 0000 0000 ) [ 00 00 00 00 00 00 ]
( 0000 0001 ) [ 00 00 00 00 00 00 ]
( 0000 0011 ) [ 00 00 00 00 00 00 ]
( 0000 0011 ) [ 06 00 00 00 00 00 ]
( 0000 0011 ) [ 00 00 00 00 00 00 ]
( 0000 0011 ) [ 19 00 00 00 00 00 ]
( 0000 0011 ) [ 00 00 00 00 00 00 ]
( 0000 0010 ) [ 00 00 00 00 00 00 ]
( 0000 0000 ) [ 00 00 00 00 00 00 ]
边界条件之场
小米随线刷包分发的刷机脚本竟然直接是错的…… (对调了 opcust 跟 opconfig ) 虽然我对中国厂商的软件分发质量没有任何期待,但这也有点太离谱了吧 #trash #xiaomi
小米随包分发两个版本的刷机脚本:
-
-
(忽略
两个脚本均提供
2024-01-17 构建的包是错的,2024-03-08 构建的包还是错的。我估计能一直错到小米 13 停止支持,不知道其它设备的脚本是不是也是错的。
另:2024-03-08 构建的包直到四月中旬才发出来……
#wtf #trash #xiaomi
-
flash_all-
flash_all_except_storage(忽略
flash_all_lock ,脑子进屎了才会给用 hyperos 的小米设备重新上锁(两个脚本均提供
.bat 和 .sh 格式, opcust 跟 opconfig 对调的错误仅存在于 flash_all_except_storage.bat 。某种程度上比全错更加离谱……2024-01-17 构建的包是错的,2024-03-08 构建的包还是错的。我估计能一直错到小米 13 停止支持,不知道其它设备的脚本是不是也是错的。
另:2024-03-08 构建的包直到四月中旬才发出来……
#wtf #trash #xiaomi
🤡1
边界条件之场
小米随包分发两个版本的刷机脚本: - flash_all - flash_all_except_storage (忽略 flash_all_lock ,脑子进屎了才会给用 hyperos 的小米设备重新上锁( 两个脚本均提供 .bat 和 .sh 格式, opcust 跟 opconfig 对调的错误仅存在于 flash_all_except_storage.bat 。某种程度上比全错更加离谱…… 2024-01-17 构建的包是错的,2024-03-08 构建的包还是错的。我估计能一直错到小米 13…
google 没有搜到任何相关结果 🤔
难道所有从 windows 刷机的用户都在用 miflash,而 miflash 会调用内置脚本而不是随包分发的错误脚本?
难道所有从 windows 刷机的用户都在用 miflash,而 miflash 会调用内置脚本而不是随包分发的错误脚本?
https://www.reddit.com/r/rust/comments/1cdqdsi/comment/l1e722d/
For instance, the orphan rule is *absolutely* a problem. It affects ecosystem scaling in multiple ways. It means that if you have a library A providing a trait and a library B providing a type, either A has to add optional support for B or B has to add optional support for A, or someone has to hack around that with a newtype wrapper. Usually, whichever library is less popular ends up adding optional support for the more popular library. This is, for instance, one reason why it's *really really hard* to write a replacement for serde: you'd have to get every crate currently providing optional serde support to provide optional support for your library as well.
In other ecosystems, you'd either add quick-and-dirty support in your application, or you'd write (and perhaps publish) an A-B crate that implements support for using A and B together. This should be possible in Rust.
There are a few potential language solutions to that. The simplest, which would likely be fairly easy and would help many applications, would be "there can only be one implementation of a trait for a type", giving a compiler error if there's more than one.
Reddit
JoshTriplett's comment on "Lessons learned after 3 years of fulltime Rust game development, and why we're leaving Rust behind"
Explore this conversation and more from the rust community
这画图跟动画真棒,比黑板直观很多(
https://www.youtube.com/watch?v=6akmv1bsz1M
https://www.youtube.com/watch?v=6akmv1bsz1M
YouTube
Something Strange Happens When You Follow Einstein's Math
Einstein was wrong about black holes, what else? Use code veritasium at the link below to get an exclusive 60% off an annual Incogni plan: https://incogni.com/veritasium
A massive thank you to Prof. Geraint F. Lewis and Prof. Juan Maldacena for their expertise…
A massive thank you to Prof. Geraint F. Lewis and Prof. Juan Maldacena for their expertise…