Hero播放视频的效果好得让我相当的惊讶！赶紧把我喜欢的MV都弄到Hero上。
以后坐车有得看啦，HOHO
ganquan@debian:~$ mencoder -of lavf -lavfopts format=mp4 -oac lavc -ovc lavc -lavcopts aglobal=1:vglobal=1:vcodec=mpeg4:vbitrate=600:acodec=libfaac:abitrate=128 -af lavcresample=22050 -vf dsize=480:360:0,scale=0:0,expand=480:360,harddup -ofps 25 -srate 22050 -o output.mp4 inputfile
跑得比往常快，出汗不少。自五一以来，蹉跎不少啊。
跑步，running
我感觉做大型开发的时候比较有用的一个插件。
安装：
1.下载looupfile，在$HOME/.vim/中解压安装。地址：http://www.vim.org/scripts/script.php?script_id=1581
2.下载genutils，在$HOME/.vim/中解压安装。地址：http://www.vim.org/scripts/script.php?script_id=197
配置：
lookupfile插件默认会使用ctags产生的tag来查找，效率很低。 lookupfile帮助文档中有介绍一个脚本来生成lookupfile插件使用的tag，查找效率一下提高很多。在项目根目录下执行下面的脚本：
ganquan@debian:~$ cat /home/ganquan/BashScript/makelookuptag
#!/bin/sh
#generate tag file for lookupfile plugin
echo -e "!_TAG_FILE_SORTED\t2\t/2=foldcase/" > filenametags
find . -not -regex '.*\.\(png\|gif\)' -type f -printf "%f\t%p\t1\n" | \
sort -f >> filenametags
在$HOME/.vimrc中加入lookupfile.vim的配置：
"-----------------------------------------------------------------------------
" lookupfile.vim 插件设置
"-----------------------------------------------------------------------------
let g:LookupFile_MinPatLength = 2 "最少输入2个字符才开始查找
let g:LookupFile_PreserveLastPattern = 0 "不保存上次查找的字符串
let g:LookupFile_PreservePatternHistory = 1 "保存查找历史
let g:LookupFile_AlwaysAcceptFirst = 1 "回车打开第一个匹配项目
let g:LookupFile_AllowNewFiles = 0 "不允许创建不存在的文件
let g:LookupFile_SortMethod = "" "关闭对搜索结果的字母排序
if filereadable("/home/ganquan/linux-2.6.34-rc4/filenametags") "设置tag文件的名字
let g:LookupFile_TagExpr ='"/home/ganquan/linux-2.6.34-rc4/filenametags"'
endif
确保LookupFile_TagExpr变量设置正确，否则还是默认使用ctags的tag来查找，速度非常慢。更多信息查看文档。
EOF
繼續開始跑步。操場上瀰漫着青春的味道。
自己留一份，懶得搜。
| 色彩 | 640×400 | 640×480 | 800×600 | 1024×768 | 1280×1024 | 1600×1200 |
| 4bits | ? | ? | 0×302 | ? | ? | ? |
| 8bits | 0×300 | 0×301 | 0×303 | 0×305 | 0×307 | 0x31C |
| 15bits | ? | 0×310 | 0×313 | 0×316 | 0×319 | 0x31D |
| 16bits | ? | 0×311 | 0×314 | 0×317 | 0x31A | 0x31E |
| 24bits | ? | 0×312 | 0×315 | 0×318 | 0x31B | 0x31F |
| 32bits | ? | ? | ? | ? | ? | ? |
EOF
在内核空间中，是不能直接使用open, read, write之类的系统调用直接访问文件的。那怎么在驱动中访问一个文件呢？
我们知道在内核中用struct file来表示一个打开的文件，file结构体中有一个字段f_op，它是struct file_operation的指针。有了这个指针，就可以对文件进行访问了。
代码如下：
struct file *filp;
mm_segment_t fs;
filp = filp_open("/path/to/your/file", O_RDWR, 0);
if(!IS_ERR(filp))
{
fs=get_fs();
set_fs(KERNEL_DS);
filp->f_op->read(...);
filp->f_op->write(...);
set_fs(fs);
filp->f_op->mmap(...);
/* ... */
}
filp_close(filp, NULL);
f_op->read()和f_op->write()的第二个参数是char __user *，也就是说是用户空间的地址，所以在驱动中直接传递kernel空间的指针，这两个函数都会返回失败-EFAULT。因此，在f_op->read()和f_op->write()之前需要使用void set_fs(mm_segment_t fs);来改变kernel对内存地址检查的处理方式。
该函数的参数fs只有两个取值：USER＿DS，KERNEL＿DS，分别代表用户空间和内核空间，默认情况下，kernel取值为USER_DS。所以可以用set_fs(KERNEL_DS);来让这个两个函数可以接受内核空间的内存。在内核空间中其他用__user修饰的参数，需要用kernel空间的内存代替时，都可以用类似的方法。
另外一个常用的函数f_op->mmap()则不需要设置fs，因为它的参数中不需要用户空间的内存。事实上，在struct file_operation中，只有read和write函数需要用户空间的内存，其他函数都不需要设置fs。
EOF