折腾 Wireless Display

很早之前就买了个Microsoft Wireless Display Adapter,之后没怎么用。前段时间尝试从 Surface Pro 6 投影过去,发现怎么搞都不成…… 就是点了之后很快就说 Couldn’t connect。 照例在网上搜了若干方法,有说驱动的,有说组策略的,有说防火墙的,反正试了都没用…… 折腾了一晚上,情况都没啥变化。 最后我怀疑有啥软件半路拦截了数据包,于是打开 Windows 用户必备工具:SysInternals Autoruns…… 发现几个残留的东西,比如穿梭啦,QQProtect啦,以及之前装的 npcap 啦…… 统统车掉之后,居然就成了…… 但是,成了之后发现,这货只能投1080p,显示器是4K的,投了很糊…… 想起来当初为啥从Win跑路了,因为出了问题不好调啊…… 另外,SysInternals真是必备工具……

Pidgin 的回归?

从前啥IM都用 Pidgin 挂着,包括MSN啦,GTalk啦,人人啦,QQ啦,…… 后来发现用 Pidgin挂的话总有些问题,比如人人的XMPP接口会自动发状态啦,QQ时常不能用啦,GTalk 变成 Hangouts 之后干脆要干掉XMPP啦,就渐渐不用 Pidgin了…… 最近天天看着那个工作得不是很靠谱的Telegram客户端 (Linux版在BSD跑当然不靠谱),再看看那个卡得不行的 Hangout 网页版,突然想到是不是 Pidgin 现在可以搞这些了,于是去看了眼…… 虽然 Pidgin 那个难产的3到现在还没出来,界面和从前一模一样 (这几年到底在干嘛……),支持各种协议的插件倒是都有了。 Telegram: telegram-purple https://github.com/majn/telegram-purple Hangouts: purple-hangouts https://bitbucket.org/EionRobb/purple-hangouts Facebook: purple-facebook https://github.com/dequis/purple-facebook 试了试看上去都还工作得不错,终于可以摆脱 Hangouts 那个卡卡的网页版了…… 这三个里面嘛,Telegram和Facebook Messenger的协议都是公开的,所以应该是可以很好支持的。Hangouts 应该是人们自己分析出来的,所以可能时不时需要更新一下。不管怎么说,至少现在都能用,图片啥的也能看见 (虽然Telegram的动画表情还不行……)。 至于 QQ 嘛,还是去 Windows 上挂着比较靠谱……

年终总结

// 于是一年啥都没写就年终总结了…… 这个blog是要完蛋了嘛…… 还是已经完蛋了…… // 之前写过年终总结么?…… Research 2016年也算PhD读到第六年了,眼看着第六年还是毕不了业,想想还是挺傻逼的…… PhD重头当然是搞项目,今年前半段搞的项目基本上是大暴死,最后还有一个月发现有人搞过了…… 怎么说呢,随便就投入一个新领域,半路改题目还没读paper,最后发现有人做过了也是活该…… 至于毕业嘛,也不知道具体是啥要求…… 目前反正新项目目标就是毕业,所以管他是不是做system投到哪里去,能毕业就行…… 之前参与搞的另一个项目倒是投了若干次终于中了,好歹也算有新paper是吧,不像去年啥都没有…… Study 怎么说呢,娱乐时间偏多,基本上不学无术……搞那个不靠谱的项目倒是学了不少Scala相关的东西,感觉这个语言语法糖太多,有时候有歧义,看都看不懂…… 虽然有时候是写起来很爽是吧,但是那谁说过还是读起来爽比较重要…… 搞这个项目还了解了一些分布式系统的东西,但里面水太深,根本就是了解了很小一部分…… GitHub上倒是有不少烂摊子项目,开了个头就没接着搞的。看时候还是应该收拾收拾…… 买了本go的书就是一直没看,好像也没啥机会用…… Gadgets 看着袁叔天天用Surface Pro 4感觉挺爽,于是也买了个。毕竟之前用了Surface 3,觉得一方面挺方便,一方面性能不行。 Surface Pro 4性能倒是好,不过bug略多,我买的时候都出了一年了还是一堆bug…… 配合着Ubuntu on Windows,感觉这货还是挺好用的,既能拿来干活也能拿来娱乐,各种Linux原生程序都能跑,微软还是厉害…… 年初买了个Pixel C,也就用来看看漫画视频之类,主要也就是床上用用。在有了Surface Pro 4之后有被闲置的可能性…… 不过最近因为懒得把Surface拿出来所以又开始活跃了…… 其他嘛还有从袁叔那里进口的PocketChip,Pine64,Fossil Q Crewmaster,有兴趣单独写算了…… Life 嘛,有些事情也是慢慢熟悉起来的么…… 虽然还有很多不确定性,但是至少也算有个计划是吧…… 总的来说嘛,好像也不是太糟糕……    

DTrace

这两天搞了一把DTrace,貌似还挺有意思的。 DTrace是个动态跟踪工具,可以在动态环境下向内核/程序中插入探头(probe),收集处理以及显示一些信息。 其实本来搞DTrace是为了一个FreeBSD的bug。搞chromecast的时候发现,IP multicast的目标mac不对。不过后来分析代码大致定位到了出问题的文件,然后在最新代码里发现这个bug已经修了(PR 185395),于是纯粹就是学习DTrace了。 一开始在我的机子上DTrace还跑不起来,后来发现是因为我跑的UEFI分支里的内核路径有些特别,于是DTrace找不到符号。打了个补丁(dt_kernel_path.patch)之后,dtrace终于能用了。 DTrace脚本的主体是一堆事件处理函数。跑DTrace脚本的时候,系统碰到某个符合的事件,就调用对应的函数。这些函数用D语言(不是那个D语言,是DTrace自己的一种语言)写成,语法和C差不多。基本的赋值/比较都能干,不过没有循环,也没有if/then/else。能控制流程的,基本上就是每个事件自带的条件,和三元操作符,也就是?:。 虽然前面那个bug是修了,我还是搞了个简单脚本来试DTrace。我希望观察arpresolve函数的参数和返回结果,也就是那个返回IP对应mac地址的函数。 arpresolve的原型是 int arpresolve(struct ifnet *ifp, struct rtentry *rt0, struct mbuf *m, const struct sockaddr *dst, u_char *desten, struct llentry **lle)int arpresolve(struct ifnet *ifp, struct rtentry *rt0, struct mbuf *m, const struct sockaddr *dst, u_char *desten, struct llentry **lle) 我希望查看dst里的ip地址,和desten里返回的mac地址。 DTrace脚本如下: fbt::arpresolve:entry /execname == "ping" && arg4 != …

Continue reading ‘DTrace’ »

Android 3.0+的MTP,以及USB debugging

Android到了3.0+有个地方特别弱智,就是USB连上显示出来不是U盘设备,而是个MTP设备…… 其他系统的MTP问题 首先这个MTP一开始就是Microsoft自己搞出来的东西,主要是Windows Media Player支持这个东西,日后才被USB那啥论坛搞成一种正式的USB类。应该是因为这个,别的系统下的支持都不怎么样。 别的系统基本上都用了libmtp库,而这个库最弱智的地方,就是刚连上的时候,会扫描所有文件做个索引…… 如果只是个音乐播放器可能还好,文件不多,但是现在是一个Android设备,那里边乱七八糟的可多了…… 于是这个索引要做个4,5分钟。想想你插上一个设备,过个四五分钟才能显示内容,那不是很sx么…… Windows下,MTP文件连上后,过一会就可以看见内容了…… 读了代码,发现他是自己递归做索引的,而且好多接口函数都会去确保这个索引存在,不在就建出来…… 根据MTP的规范,其实每次请求一个目录也就列出它的子文件和子目录。也就是说,按照规范来说,并没有啥一定要一次性拿到所有文件的必要性。看windows那边的实现也可以说明这一点。或许本来它是考虑搞个缓存提高之后速度,但是这个初次访问速度实在不能忍。而且之后访问慢慢建出来索引也可以,没必要非要一开是就建出全部的索引。 但是USB的传输速度又比较快。理论上wifi也很快,但是我拿scp也好ftp也好adb也好,速度都最多1M多,还不清楚哪儿sx了…… 所以还是要想办法搞定这个事情,难道要重写libmtp么…… Win下的MTP问题 于是我想别的系统MTP支持糟糕,Win总该不错吧?于是打开WinXP虚拟机,嘿,这个MTP还没有驱动…… 上网查,说要装WMP10,装完还是不行。再查,说可以装WMP11,装完还是不行。再查,说有个MTP Porting Kit的东西,里面有驱动。下下来装好,里里外外翻了一遍,还是没有驱动…… 后来从WMP11的wmfdist11.exe,也就是Window Media Format 11 Runtime那一部分里,翻出来若干inf以及相关文件,貌似是MTP驱动。但是手动指定到这儿,倒好像装上去了,但还是不行…… 到此基本没法,上网继续查。在查了好久之后,终于有个地方说可能和USB debugging有关系。遂关掉USB debugging,立马就好了…… 自动装好驱动,啥都能访问。一开,又不成…… 继续观察,发现不开的时候,只有一个设备,VID_22B8&PID_70A8。这个设备的兼容类型里包括了USB\MS_COMP_MTP,所以驱动匹配上了。开了之后,这个设备变成了一个复合设备,VID_22B8&PID_70A9,很神奇的就是PID加了一,估计是为了和原来的区别开来。这个东西下有俩子设备,VID_22B8&PID_70A9&MI_00和VID_22B8&PID_70A9&MI_01。后一个在装了Moto的驱动之后,显示出来是个ADB设备,也就是USB debugging用的…… 前一个名称是MTP,估计就是MTP设备,但是兼容类型里没有USB\MS_COMP_MTP!于是驱动挂不上…… 就弱智了…… 解决方法其实很简单,只要改windows\inf下的wpdmtp.inf,在匹配段里面,在 %GenericMTP.DeviceDesc%=MTP, USB\MS_COMP_MTP 之后,加上 %GenericMTP.DeviceDesc%=MTP, USB\VID_22B8&PID_70A9&MI_00 ,一切都搞定了…… 于是我很难理解,到底是哪里脑残了导致开了USB debugging就不说自己是MTP设备了…… 蛋疼啊…… 为啥Google要用MTP…… 虽说Google那边说MTP有诸多好处,例如提高了抽象层次,使得一个文件对Android和电脑都可见啦之类(老的方式系统看见了一大块数据,里面有几个分区,所以如果允许两边都看见,那只要有改动,就会导致元数据不一致…… 新的方法等于系统看见了一堆抽象的文件和目录等,所以所有操作都要告诉那边才能做…… Android那边维持着一致性……),但是选MTP这个标准真是蛋疼,你大不了Google自己搞一套+开源实现也不难啊!MTP就不是给你做任意类型文件传输的么!